Certificate Management

Certificate expiry and the renewal window

Every TLS certificate has a notBefore and notAfter date. Once the current time passes notAfter, the certificate is expired and clients will reject it with a hard error -- no warning, no bypass in most automated clients. An expired certificate is one of the most common causes of production outages, and it is entirely preventable.

The expiry window check measures how much time remains before the certificate expires and flags certificates that are approaching their expiry date:

• More than 30 days remaining -- pass. The certificate is healthy and renewal is not yet urgent.
• 7 to 30 days remaining -- warning. Renewal should happen soon. If automated renewal is configured, this window gives time to detect and fix failures before the certificate actually expires.
• Less than 7 days remaining -- failure. The certificate is critically close to expiry. If renewal has not happened by now, something is broken in the renewal pipeline.

Why certificates expire unexpectedly

Automated renewal (via ACME/Let's Encrypt, cloud provider auto-renewal, or configuration management) is supposed to prevent expiry. When it fails, the cause is usually one of:

• DNS validation failure -- ACME DNS-01 challenges fail because the DNS provider's API credentials expired, the zone was moved, or a firewall blocks the ACME client's API call.
• HTTP validation failure -- ACME HTTP-01 challenges fail because a reverse proxy, CDN, or WAF blocks the /.well-known/acme-challenge/ path.
• Credential rotation -- the API key or service account used by the ACME client was rotated without updating the renewal configuration.
• Deployment not restarted -- the certificate was renewed on disk but the web server was not reloaded, so it continues serving the old (now expired) certificate from memory.
• Monitoring gap -- the team monitors the website's HTTP response but not the certificate's expiry date. The site works fine until the exact moment of expiry, then fails with no advance warning.

Best practices for expiry monitoring

Monitor certificate expiry across all endpoints, not just the primary domain. Load balancers, API gateways, internal services with TLS, and CDN origin certificates all have independent expiry dates. Check the actual certificate served over the network, not the file on disk -- these can diverge if the server was not reloaded after renewal.

Set alert thresholds at 30 days (warning) and 7 days (critical). For Let's Encrypt certificates (90-day lifetime, renewed at 60 days), a 30-day warning means the renewal has already failed at least once.

Certificate lifetime limits

The CA/Browser Forum, the industry body that governs certificate issuance rules, has progressively shortened the maximum allowed lifetime for publicly trusted certificates:

• Before 2015 -- certificates could be valid for up to 5 years.
• 2015-2018 -- reduced to 3 years (39 months).
• 2018-2020 -- reduced to 2 years (825 days).
• 2020-present -- reduced to 398 days (approximately 13 months).
• Future -- Apple has proposed reducing to 45 days by 2028, with the CA/Browser Forum ballot approved in 2025. This will make automation mandatory for all certificate management.

The certificate lifetime check verifies that the certificate's validity period (the span from notBefore to notAfter) does not exceed the current maximum of 398 days. A certificate with a longer lifetime was either issued before the rule change (and will not be renewed with such a long lifetime) or was issued by a CA that is not complying with industry standards.

Why shorter lifetimes are better

Shorter certificate lifetimes reduce the window during which a compromised key can be abused. If a private key is stolen, the damage is limited to the certificate's remaining validity period. Revocation mechanisms (CRL, OCSP) are supposed to address this, but in practice they are unreliable: browsers soft-fail on OCSP errors, and CRL checking has been mostly abandoned by browsers due to performance and privacy concerns.

Shorter lifetimes also force automation. Manual certificate management does not scale to 90-day or 45-day renewal cycles. Organizations that automate renewal early avoid the scramble when lifetime limits decrease further.

SAN quality

The Subject Alternative Name (SAN) extension lists the hostnames (and sometimes IP addresses) that a certificate is valid for. When a client connects to example.com, it checks whether example.com appears in the certificate's SAN list. If it does not, the connection fails with a hostname mismatch error.

The SAN quality check evaluates the SAN list for issues that indicate misconfiguration or security concerns:

• Excessive SANs -- a certificate covering hundreds of unrelated domains is a shared hosting or CDN certificate. This is not inherently wrong, but it means that a compromise of any one domain's private key affects all domains on the certificate. For security-sensitive deployments, dedicated certificates are preferred.
• Wildcard scope -- a wildcard certificate (*.example.com) covers all single-level subdomains. This is convenient but means the certificate is valid for any subdomain, including ones that do not exist yet. A compromised wildcard certificate key gives an attacker a valid certificate for every subdomain.
• Internal names in public certificates -- SANs containing internal hostnames (like mail.internal or server1.corp) in a publicly trusted certificate are a policy violation. CAs are prohibited from issuing certificates for non-public names.
• Missing www variant -- if the certificate covers example.com but not www.example.com (or vice versa), users accessing the uncovered variant will see a certificate error. Most CAs include both by default, but manual CSR generation can miss this.

AIA reachability

The Authority Information Access (AIA) extension in a certificate contains URLs that clients can use to fetch missing information about the certificate chain:

• CA Issuers -- a URL pointing to the issuing CA's intermediate certificate. If the server does not send the full chain (a common misconfiguration), the client can use this URL to download the missing intermediate and complete the chain.
• OCSP responder -- a URL for checking whether the certificate has been revoked via the Online Certificate Status Protocol.

The AIA reachability check verifies that the CA Issuers URL in the certificate is actually reachable and returns a valid certificate. This matters because:

When AIA matters

If your server sends the complete certificate chain (leaf + all intermediates), AIA reachability is less critical -- clients do not need to fetch intermediates because they already have them. The AIA URL is a fallback.

But if your server sends only the leaf certificate (a common misconfiguration, especially after server migrations or certificate renewals), AIA becomes the only way for clients to obtain the intermediate. In this scenario:

• Browsers often have AIA fetching enabled and can recover from a missing intermediate by downloading it. This is why the site "works in the browser" but fails elsewhere.
• Command-line tools (curl, wget, openssl) typically do not fetch AIA URLs and will fail with "unable to verify the first certificate" or "certificate verify failed."
• Mobile apps and embedded clients usually do not implement AIA fetching.
• Internal network clients behind firewalls may be unable to reach the AIA URL even if they support fetching.

If the AIA URL is unreachable (the CA's server is down, the URL has changed, or the certificate is very old and the URL is no longer maintained), the fallback does not work and the incomplete chain causes hard failures for all non-browser clients.

Best practice

Always configure your server to send the complete certificate chain, regardless of AIA availability. Treat AIA as a safety net, not a primary mechanism. Verify chain completeness by connecting with openssl s_client, which does not fetch AIA URLs and will show you exactly what the server sends.

# Check what the server actually sends (no AIA fetching)
openssl s_client -connect example.com:443 -showcerts 2>/dev/null | \
  grep -c "BEGIN CERTIFICATE"
# Should be 2+ (leaf + intermediates). If 1, the chain is incomplete.

Putting it together: a certificate health checklist

1. Expiry window -- is the certificate more than 30 days from expiry? Is automated renewal working?
2. Lifetime -- is the certificate's total validity period under 398 days? Older, longer-lived certificates should be replaced.
3. SAN coverage -- does the SAN list cover all hostnames that resolve to this server? Are there unnecessary wildcards or excessive domains?
4. AIA URLs -- are the CA Issuers and OCSP URLs reachable? Even if you serve the full chain, unreachable AIA is a signal that the CA's infrastructure may have issues.
5. Chain completeness -- does the server send all intermediates, or is it relying on AIA as a crutch?
6. Renewal automation -- is ACME or another renewal mechanism configured, tested, and monitored? Can you prove the last renewal succeeded?