Certificate lifecycle management
Running a certificate authority is mostly clerical work: issue a certificate, get it onto the machine that needs it, notice before it expires, replace it, and be able to withdraw it early. The cryptography is settled and available in OpenSSL; what fails in practice is the tracking. vaultls was written because its author had shell scripts and no answer to “what expires next.”
The four moves
Issue: someone has to decide who gets a certificate and for what name. vaultls keeps this manual by default — only admins issue — and offers ACME as the automated path, letting Traefik or acme.sh request certificates from a private CA the same way they would from a public one. ACME is the difference between a certificate estate a person maintains and one that maintains itself.
Distribute: a certificate is useless in a database. PKCS#12 for clients, split files for reverse proxies, a ZIP of key plus certificate for SSH — each consumer wants a different container, and the gap between them is where private keys get copied around by hand.
Expire: expiry is the one security property that arrives for free: a certificate stops being a credential on a known date whether or not anyone remembers it. It is also the standard outage. Both facts come from the same design, and the operational answer in vaultls is email notification before the date.
Revoke: the hard one, and the source states why: “TLS certificates cannot be simply deleted since their validity period is cryptographically encoded.” A certificate is a signed assertion already in someone else’s hands, so withdrawal is not deletion but publication — a Certificate Revocation List naming the serials that no longer count. vaultls serves its CRL without authentication, which is the right call and also the shape of the problem: revocation only takes effect where verifiers bother to fetch and check the list, and the CA has no way to know whether they do.
Why a defender cares
Every one of these is a way to lose an access decision quietly. An expired certificate is an outage; an un-revoked one is a credential an ex-employee or a compromised host still holds; an unnoticed CA key on a mounted volume is the whole trust root. This is the zero-trust question — what a credential is worth once someone holds it — asked about the object that carries it (mutual-tls).
The corpus has one source here, and it is a tool rather than a measurement. Nothing in this spoke says how often revocation is checked in practice, or what fraction of certificate incidents are expiry versus compromise.
Related
vaultls · mutual-tls · zero-trust · defensive-security · synthesis