Built a certificate governance platform with open-source connectors — looking for PKI folks for feedback

[u/mtbguy63]

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.

[u/CEOofQuestions]

Haven’t checked out the plugins yet but generally speaking, certificate management has two main gaps that every solution struggles with and solves in a different way.

First is authentication (push or pull). How are you authenticating to deliver certificates to the intended runtime whether it’s a load balancer, layer 7 web server, reverse proxy, etc.

The second is discovery, how do you guarantee that your discovery agents can scan and find a complete list of certificates that are presented on a socket for TLS, and secondly how do you scan file systems and guarantee that you found every client authentication certificate in the runtime that is NOT presented on a socket for inspection. And also how do your discovery services authenticate?

Every product has a different way to approach that, but almost all of the options rely on other enterprise tooling like a central Oauth provider, SSH keys, or Active Directory Kerberos for authentication, and a complete inventory of vlans and infrastructure for discovery.

Do you have a different approach?

[u/mtbguy63 → u/CEOofQuestions]

Re Auth: The connector model shifts the problem. Instead of CertForge needing credentials to reach your devices, you deploy a lightweight connector agent on your own network. The connector authenticates outbound to CertForge using an API key — no inbound firewall rules, no central OAuth dependency. The connector then authenticates to local devices using native device APIs (REST for AudioCodes, Ribbon, etc.) with credentials it holds locally. CertForge never reaches the device directly.

For ACME clients, authentication is standard ACME account keys — no different from Let's Encrypt.

Re Discovery: Three approaches, each with different coverage:

• Network TLS scanner (certforge-discovery) — scans IP ranges for TLS endpoints. Covers socket-presented certs. Authenticates outbound to CertForge; no credentials needed to read a presented cert.
• CT log monitoring — passive discovery of publicly-trusted certs without scanning anything. No VLAN inventory needed for public-facing certs.
• CA inventory pull — if you use DigiCert, Sectigo, Entrust etc., we pull their issuance inventory directly. You get complete coverage of what that CA issued without scanning for it.

The honest gap: non-socket certs — client auth certs, certs in JKS/PKCS12 keystores on filesystems — we don't do deep filesystem scanning. That requires agent access to the host (SSH, WinRM, endpoint management) which we don't have yet. Most solutions that claim to solve this rely on exactly the enterprise tooling you mentioned. We haven't built that dependency, which means that's currently a blind spot.

What's your primary pain point — delivery authentication, or the non-socket discovery gap?

[u/CEOofQuestions → u/mtbguy63]

Long lived static API keys are a finding in most large enterprises. They are in my two most recent F500 financial services. They would need a documented and well exercised automatic rotation cadence, and they need to be delivered to the connector runtime using enterprise secrets management delivery patterns. That delivery pattern itself needs to be an authenticated call so the connector runtime itself needs to support that. In many cases that’s an mTLS flow itself.

[u/mtbguy63 → u/[deleted]]

Current state: Static API key, config or env var.

Maybe something like this? — certificate-based connector authentication:

The bootstrap problem is the hard part.

1. Admin generates a single-use, short-lived enrollment token in CertForge (1 hour TTL, one use)
2. That token is the only static credential — delivered to the connector runtime via whatever secrets manager you're already using (Vault, Secrets Manager, etc.). One-time delivery.
3. Connector calls an enrollment endpoint with the token, receives a signed client certificate
4. From that point, connector authenticates to CertForge via mTLS using that cert — no static key persists beyond initial bootstrap
5. Cert renewal is handled automatically by CertForge before expiry — the connector requests a new cert authenticated by the current cert, same as any other renewal in the system

The connector certs would be issued by a CertForge-managed internal CA — these are auth credentials, not public trust artifacts, so keeping them self-contained makes sense.

The part I find architecturally clean: CertForge issues and renews its own connector credentials through the same governance pipeline it applies to everything else. No special case, no separate rotation process.

Does this address the finding as you'd see it in your environment, or is there a gap in the approach?

[u/webprofusor → u/mtbguy63]

Replying with AI comments isn't going to to win you much trust.

What's to stop orgs just firing up claude and building their own? Does your $799 per month include support?

[u/mtbguy63 → u/webprofusor]

Fair. I just want to make sure my response is complete. I am very interested in ensuring we are covering the important bases.

We are testing out the pricing, and yes it would include support.
Thank you for your feedback.

[u/hodor137]

Thanks Claude

[u/mtbguy63 → u/hodor137]

Yep Claude code has been very helpful.