The most surprising thing about TLS certificates is that they don’t actually authenticate anything.
Here’s how a typical certificate lifecycle plays out, using a hypothetical example.com website.
Issue:
When example.com wants to secure its website, it generates a private key and a Certificate Signing Request (CSR). The CSR contains information like the domain name, organization details, and the public key. This CSR is sent to a Certificate Authority (CA) like Let’s Encrypt or DigiCert. The CA verifies the domain ownership (e.g., by checking DNS records or requiring a file upload to the web server). Once verified, the CA signs the CSR with its own private key, creating a digital certificate. This certificate is then sent back to example.com. The server now has its certificate (containing the public key and CA’s signature) and its private key. When a browser connects to example.com, the server presents its certificate. The browser checks the CA’s signature using the CA’s public key (which is pre-installed in the browser’s trust store). If the signature is valid and the domain name in the certificate matches the requested domain, the browser trusts the certificate and proceeds to establish a secure connection using the public key from the certificate.
Rotate:
Certificates have a limited lifespan, typically 90 days for free CAs like Let’s Encrypt, or one to two years for commercial CAs. This limited lifespan is a security feature. It ensures that if a private key is ever compromised, the window of opportunity for an attacker is also limited. Regular rotation also forces administrators to re-validate domain ownership and update their systems, reducing the chance of stale or misconfigured certificates. The process of rotation is essentially the same as issuance: generate a new private key, create a new CSR, submit it to the CA, get the new certificate, and install it on the server, replacing the old one. Automation is key here. Tools like Certbot can be configured to automatically renew certificates before they expire, downloading the new certificate and reloading the web server (e.g., Nginx or Apache) to use it.
# Example using Certbot for Nginx on Ubuntu
sudo certbot renew --nginx
This command checks all certificates managed by Certbot and renews any that are nearing expiration. The --nginx flag tells Certbot to automatically reload Nginx after a successful renewal.
Expire:
Expiration is the end of a certificate’s trusted life. When a certificate expires, browsers will no longer trust the connection. Instead of a secure connection, users will see a prominent warning message, often stating "Your connection is not private" or "This site ahead contains malware" (though the latter is a misinterpretation of certificate errors). This is a critical security mechanism. It prevents attackers from using old, potentially compromised, or revoked certificates indefinitely. The warning forces an administrator to act.
Subject: CN = example.com
Issuer: CN = Let's Encrypt Authority X3, O = Let's Encrypt, C = US
...
Validity
Not Before: Jan 1 00:00:00 2023 GMT
Not After : Apr 1 00:00:00 2023 GMT <-- This is the expiration date
If the "Not After" date has passed, the certificate is expired. The fix is straightforward: obtain and install a new, valid certificate. For automated systems, this usually means ensuring the renewal process is working correctly. If manual, it involves repeating the issuance steps.
The distinction between a certificate’s "Not Before" and "Not After" dates isn’t just about when it becomes valid and when it stops being valid; it’s also about the trust anchor’s validity. If the CA itself expires or is removed from trust stores, all certificates signed by it become untrusted, regardless of their own expiry dates.
The next concept to explore is certificate revocation, where a certificate can be invalidated before its expiration date.