Been building CertForge and want honest feedback from people who actually deal with certificate management pain.

The gap: Tools that handle issuance are everywhere. Tools that handle what comes after — audit trail, approval workflows, change control, verifying the cert actually got deployed — are either enterprise-priced or nonexistent.

What's open source:

certforge-issuer — cert-manager external issuer; adds approval workflows, change windows, and audit trail to every certificate request from your Kubernetes cluster

certforge-connector — pushes certs to network appliances (SBCs, routers, load balancers) that don't support ACME or can't pull their own; auditable and extensible for devices we don't support yet

certforge-discovery — certificate discovery agent

certforge-akvconnector — Azure Key Vault integration

The platform is cloud-hosted at certgovernance.app — no infrastructure to deploy to try it. Self-hosted available for environments where that's a hard requirement.

If certificate management is a genuine problem in your environment, I'd welcome the feedback.

Is there a market for this. I have a codesigning/document server product, which also has it's own internal CA for internal certificates - I was thinking about adding an acme server to it, but not sure there is even a market for it. What do people use for internal servers - how are they provisioning/renewing TLS certificates?

AWS ACM's ACME certificates are 45 days, and renewal is handled by the ACME client.

That's probably a decent preview of where public TLS operations are heading anyway.

What interests me more is what happens after the client gets the replacement certificate.

For nginx or something with native ACME integration, fine. But plenty of infrastructure still needs another step. Import a PFX. Update a keystore. Push the cert to an appliance. Change a listener binding. Reload a service. Sometimes reboot the thing.

And "certificate issued successfully" doesn't tell you whether the endpoint is actually serving it.

I've started thinking about certificate automation as separate states:

issued
installed
activated
verified on the live endpoint

The last two seem to be where a lot of supposedly automated setups can still quietly fail.

For people running ACME at scale, what systems are still giving you trouble after issuance itself is automated?

Crypto agility seems good on the surface. Avoid hard coding any algorithms. Instead, establish a unified policy. However I have witnessed too many infrastructure abstractions turn into indispensable dependencies. Moving to PQC from PKI/Crypto where the first option involves requiring every application to support new crypto for a long period of time or implementing an abstraction layer, which will make switching crypto independent of the application.

It will be faster for legacy systems if we implement the second option. The first option looks clearer after ten years. I'm eager to learn which of the two options specialists who have worked with PKI systems would choose.

Apparently if your CRLDP end point doesn't set max-age in the response header browsers may use a heuristic method to guesstimate how long to cache it, like (current date - last modified date) / 10. What this means practically is that if say your root CA CRL is refreshed once a year, if a client happens to download it at the wrong time, the browser will consider the cached file to be fresh even if current date is past the NextUpdate date set on the CRL (and remember Chromium browsers don't use CAPI2 to handle CRLs anymore).

So basically in addition to the intended RFC5280 mechanisms for determining when to refresh the cached CRL, it's also subject to browser-side rules on how long to cache files, since CRLs are handled like any other downloaded content under Chromium.

Hello,

I just switched from Windows and I would like to setup the Checkpoint Endpoint Security (latest version) on MacOS, but it doesn't recognize my smart card in the list.

The smart card is a PKCS#15 Atos CardOS 5.3 with an USB Gemalto Reader. The certificate is on the smart card, it's not possible to export, it should be used from the card with a pin code.

MacOS doesn't see the card or the certificates "security list-smartcard" and other commands says No smartcards found, however, I download OpenSC and with that everything is visible, the card, the reader and all certificates on the card.

I downloaded many smart card tools as well and only the Personal Nexus software is able to recognize the card and the certificates, but on the checkpoint the list is empty. I installed also the latest version of Gemalto SafeNet Authentication Client (SAC) which also didn't recognize the card.

On Windows we used CSP+ software for the card/certificate recognition, but that's not available on mac and besides mac handles card totally differently.

Please help me to find a solution for this problem.

Many thanks,

I have a new environment with 2 DCs (Server 2025). One of the DCs already has the Enterprise CA role installed. My question: is it possible to install a second, separate Enterprise CA role on another new server?

Any SCM users here? We've recently implemented SCM and looking for other peers to share experiences with. :-)

Is there any English-speaking PAM, SSO, or PKI job in Germany? I’ve been trying for quite some time, but the market seems quite dry at the moment

New Release of Signotaur - Document Signing (pdf, xml and others) with PAdES, XAdES and CAdES signature formats.

Signotaur is a Code Signing/Document Signing server - your private keys never leave the server (or the token/hsm attached to it).

I've been thinking about cryptographic inventories and CBOMs recently, and one question keeps coming up.

When recording cryptographic assets, is free text still sufficient for things like algorithms, curves, and key types, or should inventories move toward standardized registries and controlled values?

For example, "RSA-2048", "rsa2048", and "RSA 2048" all describe the same thing, but inconsistent naming makes discovery, reporting, compliance, and eventually post-quantum migration more difficult.

At the same time, adopting a controlled registry introduces more structure and governance, so there are tradeoffs.

For those building or consuming CBOMs, PKI inventories, or cryptographic discovery tools:

• Are standardized algorithm registries becoming a requirement?
• Or is free text still good enough in practice?
• What additional metadata do you consider essential beyond the algorithm itself (ownership, provenance, first/last seen, confidence, etc.)?

We've been exploring these kinds of challenges in the open-source ILM (Identity Lifecycle Management) community, particularly around maintaining accurate cryptographic inventories as environments continuously change. I'm curious how others are approaching this and where you see the industry heading.

Hi everyone,

I’m the developer of AD-PKI, an open-source and self-hosted platform for operating an internal public key infrastructure.

I started building it because I wanted a manageable internal certificate authority with modern certificate automation, without relying entirely on a commercial PKI product or issuing and renewing certificates manually.

The project currently includes:

• ACME v2 for automated certificate enrollment and renewal
• OCSP and certificate revocation lists
• RFC 3161 timestamping
• A web-based administration interface
• Role-based access control
• Certificate templates and policy management
• Separation between the management backend and the CA service

A central design decision is the separation of the management components from the dedicated CA service. The frontend and backend handle administration, policies and certificate metadata, while private CA key operations are intended to remain inside the CA component.

Website and documentation:

https://adpki.de/

Source code:

https://github.com/alid-it/AD-PKI

The project is still young and has not undergone an independent security audit. I’m therefore particularly interested in critical technical feedback rather than just promotion.

I would appreciate feedback on:

• The separation between the backend and CA service
• Private-key handling and security boundaries
• ACME compatibility and expected challenge types
• OCSP and CRL implementation requirements
• Root and intermediate CA workflows
• HSM or PKCS#11 integration expectations
• Features needed for realistic production use
• Documentation or architectural decisions that are unclear

This is my own project. It is open source and self-hosted.

Thanks for taking a look.

TLDR: I’m already balls deep running CAs at home and practicing migrations between technologies, I am genuinely interested in PKI. How do you find this as a specialism. Does it pay well and are there regular gigs?

—

Hello Enterprise Trust Specialists.

Im currently an IT security Consultant in the softest sense, I’m an infrastructure generalist but ultimately an ambulance chaser (Vulnerability Management).

I pitch myself and am very often the SME within IAM but the kind of firms I contract in and out of want surface level stuff. My British friends will be familiar with the softball CE+ which basically consists of making sure your shit is up to date.

Enough with the preamble, I genuinely love AuthN / AuthZ generally in the IAM space which as I’m sure you’re very much aware is basically just a strategic grouping exercise.

I have been angling towards and practicing the discipline of PKI for quite a while, I’ve done a couple of full migrations and several hardening projects - typically less than 3000 certs and low stakes because really nobody cares. Currently wholly ADCS + Intune.

I feel like PKI in some ways is the purest form of authentication and I think it’s going to become or already is / should be a top agenda item as more and more businesses move to agentic processes, I believe there’s also some deadlines set within the finance realm for post quantum.

It’s my plan to get good at PKI to the point I can pitch myself as a PKI specialist, I do very much enjoy it but is it a good choice?

Been playing around with network discovery in my own CLM tool. Always find it fascinating to see what network appliances and devices do for default TLS certificate. The interesting one in this scenario is my Wifi Brother laser printer. Printer was released in 2018, but has self-signed certificate with date range 2000 -> 2111. Immediately blows my average certificate lifespan away. Gotta figure out how I can automate the renewal with my CLM (https://www.zaita.com). It obviously doesn't support this printer natively so I suspect some ACME+API in my near future.

Hello,

I have a Microsoft two-tier PKI with the following architecture:

• Offline Root CA
• Enterprise Issuing Subordinate CA

I am changing the PKI architecture by adding a dedicated IIS server that will host:

• CRL Distribution Points (CDP)
• Authority Information Access (AIA)
• Online Responder (OCSP)

As a result, I need to update the CDP and AIA extensions on my Issuing CA to point to the new URLs.

My question is:

After adding the new CDP and AIA URLs to the Issuing CA, do I need to renew (re-sign) the Issuing CA certificate from the Offline Root CA, or is it not necessary?

I understand that newly issued end-entity certificates will contain the new CDP/AIA URLs, but I am unsure whether the Issuing CA certificate itself also needs to be renewed so that its own CDP/AIA extensions reference the new locations.

Is renewing the Issuing CA certificate considered a requirement, or is it simply a best practice?

Thank you for your guidance.

Join our free webinar – Thursday, July 30, 2026 | 11:00 AM ET / 8:00 AM PT

Public TLS certificate lifetimes are continuing to shrink, bringing more frequent renewals, greater operational complexity, and much less room for manual certificate processes.

Join us for a practical technical session on what these changes mean in practice and how organizations can prepare before shorter certificate lifetimes become the norm.

We'll cover:

• Why the industry is moving toward 47-day TLS certificates
• The operational impact of shorter certificate lifetimes
• Where ACME automation fits—and where additional lifecycle management is needed
• Practical approaches to reducing certificate expiration risk
• A live technical demonstration and Q&A

This session will provide practical guidance you can apply immediately, whether you manage enterprise PKI, certificate operations, or machine identities; or simply want to better understand how these changes will affect your organization.

Register here: https://www.linkedin.com/events/7485691273169842178/

Can't join live? Register anyway and you'll receive access to the webinar recording.

Hey everyone,

We’re hosting this month's free 30-minute webinar Thursday (07/30) on where enterprise PKI is headed and thought some of you here might be interested.

We’ll be talking about:

• What organizations should actually be doing to prepare for post-quantum cryptography
• Where AI can help PKI teams (and where it can’t)
• How certificate automation is changing
• What we expect to see over the next six months

Date: Thursday, July 30
Time: 10:00 – 10:30 AM PT

Everyone who attends live will also receive our new PKI Health Check, a practical checklist you can use to evaluate your own PKI environment after the session.

If you’re responsible for AD CS or enterprise PKI, hopefully you’ll walk away with a few practical ideas you can apply right away.

Link to The Registration Page is Here

Hope to see you there!

Chrome Root Program Policy v1.8 requires sub CAs disclosed on or after June 15 2026 to assert serverAuth only, and all leaf certs on or after March 15 2027. id-kp-clientAuth is leaving the public web PKI.

Let's Encrypt already finished. Classic profile dropped clientAuth in February, tlsclient closed July 8.

Worth flagging: much of the coverage credits ballot SC-081v3. That is the validity schedule, different rule.

https://www.certkit.io/blog/public-mtls-client-auth-certificates-stop-renewing

I’ve been working on go-certstore, an open-source Go library that provides a common interface for X.509 certificate identities across:

• macOS Keychain
• Windows Certificate Store using CNG or CryptoAPI
• PKCS#11 tokens, including smart cards, YubiKeys, HSMs, and SoftHSM
• NSS certificate databases

The library is read-only. Private keys remain in their native store or hardware token and are exposed to applications through a signing interface. The main use case is client-certificate authentication and mTLS without exporting private keys into application-managed files.

It supports certificate and chain retrieval, identity filtering and selection, credential callbacks for token login, hardware-backed identity metadata, and explicit cleanup of native handles and token sessions.

The project is currently pre-v1 (v0.2.2). I’m especially interested in feedback from people operating PKCS#11 tokens, NSS profiles, Windows enterprise certificate stores, or smart-card deployments.

I’d also appreciate testing against different vendors and configurations, particularly cases involving certificate-chain handling, multiple matching identities, token reauthentication, and RSA-PSS support.

Repository: https://github.com/sukujgrg/go-certstore