CertPilot PKI lifecycle
PKI and certificate lifecycle management Open source · Self-hosted

Certificates expire quietly. Authorities take the estate with them.

CertPilot watches the CA hierarchy your organisation runs on, and every certificate under it, on one clock.

Frontispiece The console, photographed
The CertPilot dashboard. A logarithmic expiry horizon runs across the top, certificate authorities plotted above the axis and certificates below; one issuing CA sits seven days out, marked critical in red. Beneath it, counts of authorities and certificates, a table of what needs attention, and a live activity feed.
Dashboard — one issuing CA at seven days, forced critical Photographed against a seeded estate, not a mockup
§ 01
The problem

An expiring issuing CA takes down everything it ever signed, and no amount of certificate automation helps once that has happened.

So this watches authorities first and certificates second. Roots and intermediates are the objects whose failure is unrecoverable, and they are the ones nobody has a renewal script for.

§ 02   Plate I  —  The expiry horizon Logarithmic, 1 day to 10 years
Certificate and authority expiry on a logarithmic axis A time axis from one day to ten years. Because the axis is logarithmic, everything expiring inside ninety days occupies the left half of the width instead of collapsing into a sliver. As the page is scrolled the clock runs forward and each mark migrates left. 1d7d 30d90d 1y2y 5y10y AUTHORITIES prod-issuing-ca 18 days corp-intermediate 240 days corp-root 7.0 years CERTIFICATES
today Keep scrolling. The clock runs forward.
§ 03
The axis

Ten years on one screen, without losing next Tuesday.

On a linear axis, everything expiring inside a quarter collapses into the first two percent of the width. The certificate with four days left sits on top of the one with forty.

The plate above is logarithmic. Half the width is spent on the first ninety days, which is where every decision actually gets made, and a root valid until 2033 still has somewhere to sit.

§ 04
The hierarchy

Three tiers, and only one of them ends an estate.

A certificate is only as good as the path above it. Every tier is signed by the one before it, so an authority that lapses invalidates everything beneath it at once, whatever the expiry dates on those leaves happen to say.

Root CA 10 to 20 years

Self-signed, and kept offline. It signs intermediates and nothing else. Long-lived enough that most teams never renew one, which is also why nobody has a procedure when the day arrives.

Intermediate CA 5 to 10 years

The working delegate. Keeping the root offline means this is what actually signs, and cross-signing here is what lets a hierarchy be rotated without redistributing a new trust anchor.

Issuing CA 2 to 5 years

Signs the certificates your services actually present. This is the one that ends an estate: every leaf it ever signed stops validating the moment it lapses, and its own renewal is the one job no automation is watching.

§ 05
Plate II

A certificate, as CertPilot reads it.

Version
3 (0x2)
Serial
4a:7f:2c:91:e8:03:b5:6d:11:c4
Sig. algorithm
ecdsa-with-SHA384
Issuer
CN=corp-intermediate, O=Example Ltd, C=GB
Subject
CN=api.internal.example.com, O=Example Ltd
Public key
EC, prime256v1 (256 bit)
Not before
2026-03-14 09:22:41 UTC
Not after
 
SAN
DNS:api.internal.example.com
DNS:api-canary.internal.example.com
Key usage
Digital Signature, Key Encipherment
Ext. key usage
TLS Web Server Authentication
AIA / OCSP
http://ocsp.example.com
CRL DP
http://crl.example.com/corp-intermediate.crl
SHA-256
d3:9a:1f:0c:74:b8:e2:55:af:36:90:cd:12:7e:4b:a8:
61:df:20:3c:95:e7:48:1a:6b:02:fd:59:88:34:c1:76
Key custody
AGENT   the private key never reaches CertPilot
Discovered via
CT log — crt.sh
Renewal lead
30 days
Deploys to
2 targets, waves 0 and 1

Nine of those fields are description. Two carry a clock, and one of those two is the reason this product exists. Provenance cannot answer custody: a certificate signed from a CSR is requested like any other and CertPilot holds no key for it, so anything deciding whether a key can be exported has to read the custody field rather than infer it.

§ 06
What it does
01

Watches the hierarchy

Roots, intermediates and issuing CAs, with expiry, CRL freshness and OCSP status on each. A revoked authority is forced critical on every sweep, from the recorded status rather than the last check.

02

Issues through gateways

Self-signed, ACME and HashiCorp Vault, each its own process speaking one gRPC contract. Adding a CA vendor does not mean touching the control plane.

03

Renews before anyone is paged

A durable queue with leases and retries. No leader election, so any replica can run it, and a restart mid-renewal does not lose the job.

04

Deploys in declared waves

Order lives on the target and is copied onto the job when it is enqueued, so reordering cannot disturb a rollout already under way. A canary is one target in the lowest wave.

05

Finds what nobody registered

Network scans, Certificate Transparency logs, cloud inventory, and host agents that report the certificate sitting in a file behind two firewalls.

06

Knows who holds the key

Every certificate records custody: CertPilot, an agent, or external. How it was discovered cannot answer that, and anything deciding whether a key may be exported has to read it.

§ 07
Verification

Claims a PKI team can verify rather than take on trust.

01

The audit log is chained with a key the database does not hold

Every entry carries a gapless sequence number, its predecessor's tag, and an HMAC over both, keyed from a subkey of the master key. An attacker holding only the database can alter a row and cannot forge a tag that agrees with it.

02

Revocation asks the CA first and records only what it accepted

A row can never read revoked while the certificate still answers handshakes. The health sweep builds a real OCSP request and verifies the responder's signature, the delegation, and that the answer is about the right certificate.

03

A replayed agent request is refused, and the signature is the nonce

Ed25519 is deterministic, so an identical request carries an identical signature. The core stores the ones it has accepted and refuses a repeat, with no protocol change and no clock to keep in sync.

04

The identity provider says who you are, CertPilot says what you may do

Roles live in CertPilot's own table, keyed on issuer and subject. A claim in a token cannot promote anyone, and suspending an account ends every one of its sessions immediately.

§ 08
Questions

The four that come up first.

Q1How is this different from certbot or cert-manager?
Those get you a certificate, and they do it well. This is everything around it: what you already have, where it is installed, whether it meets your policy, and getting the renewed one onto the machine that serves it.
Q2Does CertPilot hold my private keys?
Only if you ask it to. Supply a signing request and the key never arrives — it stays in the HSM or the host that made it, and the record says so. Keys it does hold are sealed before they reach the database. The agent generates its own and sends nothing back.
Q3What happens when CertPilot is down?
Nothing it has already issued stops working. Certificates are served by your own infrastructure, not proxied through this. Renewals queue and resume, and a replica that dies mid-renewal releases the job rather than losing it.
Q4Which certificate authorities work?
ACME, so Let’s Encrypt, ZeroSSL and anything else speaking RFC 8555. HashiCorp Vault’s PKI engine. And a self-signed gateway, so a first run needs an account nowhere.
§ 09
Run it

A control plane you run, and a schema you apply deliberately.

The server never migrates itself. A schema change is something an operator runs, not a side effect of a replica restarting mid-deploy.