TLS Certificate Lifecycle: Provision, Rotate, and Expire (2026)

A TLS certificate isn’t just a static key; it’s a dynamic document that expires, and managing that expiration is a continuous process, not a one-off task.

Let’s see what this looks like in the real world. Imagine a web server, say Nginx, serving traffic over HTTPS.

server {
    listen 443 ssl;
    server_name example.com;

    ssl_certificate /etc/nginx/ssl/example.com.crt;
    ssl_certificate_key /etc/nginx/ssl/example.com.key;

    # ... other configurations
}

Here, /etc/nginx/ssl/example.com.crt is the public certificate, and /etc/nginx/ssl/example.com.key is the private key. When a browser connects, it gets the certificate and verifies it against a trusted Certificate Authority (CA). This verification includes checking if the certificate is still valid (i.e., not expired).

The lifecycle of this certificate involves three main stages:

Provisioning

This is the initial act of obtaining a TLS certificate. You decide on the scope of the certificate (e.g., a single domain like example.com, or a wildcard like *.example.com). Then, you generate a Certificate Signing Request (CSR). This CSR contains your public key and identifying information (like your organization’s name and domain name).

You submit this CSR to a Certificate Authority (CA). The CA verifies your identity and control over the domain. Once satisfied, they issue a signed certificate. For publicly trusted certificates, you’ll typically use CAs like Let’s Encrypt, DigiCert, or Sectigo. For internal services, you might use your own private CA.

A common way to provision certificates, especially with Let’s Encrypt, is using a client like Certbot.

sudo certbot certonly --nginx -d example.com -d www.example.com

This command interacts with Let’s Encrypt, proves domain ownership (often by placing a file on your web server), and then installs the certificate for Nginx.

Rotation

Certificates have a limited lifespan. For publicly trusted CAs, this is typically 90 days (Let’s Encrypt) or 1 year (others). Rotation is the process of renewing an expiring certificate before it expires. This is crucial to avoid service interruptions. If a certificate expires, clients will see security warnings, and connections will fail.

Automating this process is key. Tools like Certbot can be configured to automatically renew certificates.

sudo certbot renew

When run periodically (e.g., via a cron job), certbot renew checks all installed certificates and renews any that are nearing expiration. It will automatically re-issue the certificate and, if configured, reload your web server to start using the new one. The typical renewal check happens twice a day, and Certbot will only renew certificates that are due to expire within 30 days.

The renewal process often involves re-validating domain ownership with the CA. For Let’s Encrypt, this might be done using the http-01 challenge (placing a file on the web server) or the dns-01 challenge (creating a DNS TXT record).

Expiration

This is the end of a certificate’s validity period. If a certificate is not rotated before its expiration date, it becomes invalid. Browsers and other TLS clients will reject connections, displaying errors.

• Browser Error Example: "Your connection is not private" or "NET::ERR_CERT_DATE_INVALID".
• Server-Side Impact: Applications that rely on these certificates for secure communication will fail. For example, an API gateway might stop accepting requests, or an internal service might be unreachable.

The primary cause of expiration is a failure in the provisioning or rotation process. This could be due to:

1. Cron Job Failure: The scheduled task responsible for running certbot renew might have failed to execute or completed with an error. Check cron logs (/var/log/syslog or /var/log/cron) for relevant entries.
2. Certbot Configuration Issues: The Certbot configuration itself might be broken, preventing it from successfully renewing. Examine Certbot’s logs, usually found in /var/log/letsencrypt/letsencrypt.log. Look for specific errors during the renewal attempt.
3. Domain Validation Failure: The CA might fail to validate domain ownership during renewal. This can happen if the web server is down, firewall rules block the validation process, or DNS records are misconfigured. Ensure your web server is accessible from the internet on port 80 (for http-01) and that DNS records are correct.
4. Rate Limits: CAs like Let’s Encrypt have rate limits to prevent abuse. If you’ve tried to renew too many times unsuccessfully, you might be temporarily blocked. Check the CA’s documentation for current rate limits.
5. Configuration Drift: Manual changes to Nginx configuration or firewall rules might interfere with Certbot’s validation or renewal process. Ensure Nginx is configured to serve the validation file and that no firewalls block port 80.
6. Expired Private Key: While less common for provisioned certificates, if you’re managing your own keys, the private key associated with the CSR might have been generated with an expiration date, or it may have been compromised and revoked.

The immediate consequence of an expired certificate is that clients can no longer establish a secure connection. They will see an error message, and the service will be unavailable until a valid certificate is installed.

The next hurdle you’ll encounter is likely related to ensuring your certificate’s private key is protected and not exposed.