Certificate management is the practice of discovering, requesting, issuing, installing, monitoring, renewing and revoking digital certificates, plus protecting their private keys. Done well, it prevents expiry outages and limits damage from compromised keys. It needs an inventory, named owners and automation.
What is a certificate for?
A digital certificate binds a public key to an identity, such as a domain name, a person or a device. RFC 5280 defines the Internet X.509 public key infrastructure profile, including certificates and certificate revocation lists. TLS uses these certificates so a client can check it is talking to the right server before encrypting traffic.
Certificates also appear outside web servers: service to service authentication, code signing, device identity, email signing and VPN access. Every use needs the same care.
What are the lifecycle stages?
NIST SP 1800-16 gives guidance on running a formal TLS certificate management programme and shows an automated proof of concept for preventing, detecting and recovering from certificate-related incidents. The stages below follow that general shape.
Discover. Find every certificate in use, including those nobody remembers issuing.
Request and issue. Generate a key, create a request, validate ownership and receive the certificate from an authority. RFC 8555 defines ACME, a protocol that automates validation and issuance between an authority and an applicant.
Deploy. Install the certificate and key where the service needs them, and reload the service.
Monitor. Watch expiry dates, configuration and unexpected new certificates.
Renew. Replace the certificate before it expires, ideally automatically.
Revoke. If a key is lost or a certificate was wrongly issued, tell the authority and clients to stop trusting it. RFC 5280 covers revocation lists, and ACME includes revocation as a management function.
Retire. Remove certificates and keys from systems that no longer need them.
Why does it keep going wrong?
Ownership. A certificate gets issued for a project and the project ends. The reminder email goes to a person who has left. A service stops working on the expiry date.
Scale also matters. The CA/Browser Forum has scheduled a reduction of the maximum validity of publicly trusted TLS certificates from 398 days to 47 days between March 2026 and March 2029. That turns a yearly task into one every few weeks, and manual handling does not keep up.
What does a constructed example look like?
An engineering team finds 340 certificates in a discovery scan. Ninety are for hostnames that no longer exist. Forty are issued by a private authority and have five-year lifetimes. Twenty-two have no recorded owner. They assign owners, delete the dead ones, move public certificates to automated renewal, and put the private ones on a calendar with alerts at 60 and 30 days. The first test of the new process is an expiry that arrives and nobody notices, because it renewed itself.
What about keys?
The private key is the secret that makes a certificate meaningful. Generate keys on the system that will use them where possible, restrict file access, and avoid copying them between servers or into source control. Prefer a new key at each renewal. For high value keys consider hardware-backed storage. Secret scanning on repositories catches keys committed by mistake.
How to check or apply this
- Run discovery: certificate authority logs, scans of hosts and ports, load balancer and ingress configs.
- Record owner, purpose, issuer, expiry and where the key lives for each.
- Automate renewal for public certificates with ACME, and test a forced renewal.
- Alert on upcoming expiry to a team channel, and on new certificates for your domains.
- Write and rehearse a revocation procedure for a leaked key.
- Review the inventory quarterly and retire what is not used.
Quick check
What is the most common cause of certificate outages?
Expiry of a certificate nobody was tracking, usually because the owner changed. An inventory with owners and automated renewal addresses that.
What is ACME?
A protocol defined in RFC 8555 that lets a certificate authority and an applicant automate domain validation and issuance.
Sources
- NIST SP 1800-16, TLS Server Certificate Management
- RFC 5280, Internet X.509 PKI Certificate and CRL Profile
- RFC 8555, ACME
- CA/Browser Forum, Ballot SC081v3
Last reviewed: 18 October 2026.
