SSL certificate lifecycle management covers everything that happens to a certificate from the moment it’s requested to the moment it’s renewed or replaced. For teams managing more than a handful of domains, this process quickly becomes one of the most error-prone areas of infrastructure work – and the consequences of getting it wrong range from browser warnings to complete service outages.
More Phases Than Most Engineers Expect
Most engineers think about SSL certificates in two moments: when they’re installed and when they expire. In practice, the lifecycle has at least six distinct phases, each with its own failure modes.
Those phases are: domain validation and certificate request, CA processing and issuance, installation and chain verification, ongoing monitoring, renewal initiation, and replacement or revocation when needed. Skipping the middle phases – especially monitoring – is where most production incidents originate.
Phase 1: Certificate Request and Domain Validation
Before a certificate is issued, the Certificate Authority (CA) needs to verify that the requesting party controls the domain. For Domain Validation (DV) certificates, this happens through DNS records, HTTP file challenges, or email verification. For Organization Validation (OV) and Extended Validation (EV) certificates, the process also includes manual business verification.
A common mistake here is requesting a certificate that doesn’t match the actual hostnames in use. If your application serves traffic on both example.com and www.example.com, your certificate needs to cover both – either as a multi-domain (SAN) certificate or a wildcard. Missing a subdomain at this stage means a certificate mismatch error the moment traffic hits that host.
Phase 2: Issuance and Chain Integrity
Once the CA issues the certificate, you receive not just the end-entity certificate but also the intermediate certificates that form the chain of trust back to a trusted root. This is where a surprising number of installations go wrong.
Installing only the leaf certificate without the intermediates causes TLS handshake failures on clients that don’t have the intermediate cached. Some older mobile clients and embedded devices are particularly unforgiving here. Always verify the complete certificate chain after installation using openssl s_client -connect yourdomain.com:443 -showcerts to see exactly what the server is presenting.
Phase 3: Post-Installation Verification
After installation, several things need to be confirmed before you can consider the certificate live and healthy:
1. The certificate is valid for all intended hostnames, including www and non-www variants.
2. The full chain is present and correctly ordered.
3. HTTPS is enforced – HTTP traffic redirects rather than serving content in the clear.
4. HSTS headers are in place if required by your security policy.
5. There are no mixed content warnings (HTTP resources loaded on HTTPS pages).
6. OCSP stapling is configured if you’re optimizing for TLS performance.
Each of these can be independently broken. A certificate that validates correctly but has HSTS misconfigured or serves mixed content still exposes users to risk. Understanding how certificate validity periods work also matters here – with browsers pushing toward 90-day maximums, the window between installation and renewal is shrinking faster than many teams realize.
Phase 4: Ongoing SSL Monitoring
This is the phase that manual processes skip most often, and it’s also the most critical. A certificate that’s healthy at installation can become problematic through CA revocation, configuration drift, cipher suite deprecation, or simply the passage of time.
Revocation is particularly underappreciated. CAs can revoke a certificate at any time – due to key compromise, a vulnerability in the CA’s own systems, or administrative error. Without active monitoring, a revocation may not surface until users start seeing browser errors. Certificate Transparency logs provide another signal: if an unauthorized certificate has been issued for your domain, CT log monitoring will catch it early.
Effective SSL monitoring goes beyond expiration countdown. It should validate the chain, test the handshake, verify OCSP status, and confirm that the certificate actually matches the domain being served.
The Renewal Window: Where Most Outages Originate
The renewal phase accounts for the largest share of SSL-related production incidents. The typical failure pattern: a certificate was set to auto-renew via a cron job or ACME client, the job silently failed due to expired credentials, changed DNS configuration, or rate limits, and nobody noticed until the certificate expired.
A 90-day Let’s Encrypt certificate that starts renewal attempts at day 60 gives a 30-day window to catch and fix failures. A one-year commercial certificate with only a 30-day alert gives far less margin. Preventing renewal failures requires treating the renewal process itself as a monitored system – not just a background task that’s assumed to work.
Best practice is to trigger renewal at 30 days before expiration for short-lived certificates, and at 60 days for longer-validity certificates. This gives enough runway to handle edge cases: CA outages, DNS propagation delays, validation failures that need manual intervention, or organizational approval processes for OV and EV certificates.
Revocation and Decommissioning
Not every certificate reaches its natural expiration. Revocation becomes necessary when a private key is compromised, when the server it’s installed on is decommissioned, or when the issuing CA experiences a trust incident.
The process is often treated as an afterthought, but revoked certificates left installed on servers create confusing error states for users. Once revoked, a certificate should be removed and replaced – not just noted in a ticket. For servers being decommissioned, certificate revocation and removal belongs on the shutdown checklist, not in optional post-shutdown cleanup.
The Myth That Auto-Renewal Replaces Active Management
Many teams believe that configuring ACME-based auto-renewal via Certbot, acme.sh, or a cloud provider’s managed certificate service means they no longer need to think about SSL certificate lifecycle management. This is one of the most persistent and dangerous misconceptions in the field.
Auto-renewal handles the renewal transaction – it does not monitor whether the renewed certificate was actually installed correctly, whether the chain is valid, whether configuration has drifted since the last renewal, or whether the certificate still covers all required hostnames. Teams that rely exclusively on auto-renewal and skip active monitoring regularly discover certificate issues the same way their users do: through browser errors. The case for proactive certificate management applies even when renewal is automated.
FAQ
How long does an SSL certificate last, and when should I start the renewal process?
Publicly trusted SSL/TLS certificates currently have a maximum validity of 398 days, with the CA/Browser Forum moving toward 90-day maximums. As a rule, begin renewal at least 30 days before expiration for short-lived certificates and 60 days for longer ones. For OV and EV certificates that require manual validation, 60 days minimum is essential to handle unexpected delays.
What is the difference between certificate expiration and certificate revocation?
Expiration is a scheduled end-of-life – the certificate stops being trusted after its validity period ends. Revocation is an emergency action where the CA marks a certificate as untrustworthy before its natural expiration, triggered by a key compromise or security incident. Both states produce browser errors for end users, but revocation can happen at any time without advance warning.
Does managing wildcard SSL certificates require a different approach?
Yes. A wildcard certificate (*.example.com) covers all first-level subdomains under a domain, which means a single compromised private key affects all subdomains simultaneously. Lifecycle management for wildcards should include stricter key storage practices, and post-renewal verification should be tested across a representative set of subdomains – not just the primary hostname.
Building a Repeatable Process
The teams that handle SSL certificate management well share a common trait: they treat certificates as infrastructure assets with documented lifecycles, not as one-time configuration steps. This means maintaining an inventory of all certificates in use – with issuance dates, expiration dates, responsible owners, and renewal procedures documented in one place.
Automated monitoring that validates full certificate health closes the gap between what auto-renewal promises and what it actually delivers. A well-managed SSL lifecycle means the next certificate expiration is never a surprise, renewal failures surface within hours rather than days, and the security posture of every HTTPS endpoint is visible at a glance.