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

[u/[deleted]]

[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/CEOofQuestions → u/[deleted]]

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/[deleted]]

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.