SSL/TLS HTTPS / networking ssl tls certificate https
Nina Johansson Site Reliability Engineer

SSL certificate has expired

An expired SSL certificate means your website is inaccessible and insecure; this guide explains how to identify and fix it.

What This Error Means

When you encounter the "SSL certificate has expired" error, it signifies that the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) certificate presented by a server is no longer valid. Every SSL/TLS certificate has a defined validity period, marked by notBefore and notAfter dates. This error means the current date falls after the notAfter date specified in the certificate.

In practical terms, this error prevents browsers and other clients from establishing a secure, encrypted connection with your server. Browsers will typically display a severe warning message, such as "Your connection is not private," "NET::ERR_CERT_DATE_INVALID," or "Potential Security Risk," often with a prominent red padlock or "Not Secure" indicator. For API clients or backend services, this often results in connection failures, SSLHandshakeException or similar errors, leading to service disruption. The core purpose of an SSL/TLS certificate is to verify the identity of the server and encrypt traffic; an expired certificate undermines both, rendering the connection untrustworthy and potentially vulnerable.

Why It Happens

SSL/TLS certificates are designed with finite lifespans for several critical reasons, primarily security. Shorter validity periods reduce the window of opportunity for attackers to exploit compromised private keys and encourage more frequent certificate rotations, which is good security hygiene. While this design is robust, it also means certificates will expire if not proactively renewed and replaced.

The root causes typically fall into a few categories:

  1. Automated Renewal Failure: For many, especially those using Let's Encrypt, certificate renewal is automated via clients like Certbot. If this automation fails due to misconfiguration, permissions issues, network blocks, or changes in the environment, the certificate will expire silently until it's too late.
  2. Manual Oversight: In environments where certificates are renewed manually (often with commercial Certificate Authorities), it's easy to miss renewal notifications, especially if the responsible person is on leave, has left the company, or if the notification email goes to an unmonitored inbox.
  3. Time Drift on Server: Less common but equally problematic is when the server's system clock is significantly out of sync with real-world time. If the server believes the current date is after the certificate's notAfter date, even a perfectly valid certificate will appear expired to that server, and consequently, to clients connecting through it if the server is performing any SSL offloading or proxying.
  4. Misconfigured Deployment: Sometimes, a certificate is successfully renewed, but the new certificate files are not correctly deployed to the web server, load balancer, or CDN, or the services are not reloaded to pick up the new configuration.

Common Causes

In my experience, encountering an expired SSL certificate in production is almost always a result of one of these specific scenarios:

  • Certbot or ACME Client Cron Job Failure: This is perhaps the most frequent culprit for Let's Encrypt users. I've seen this when the cron job stops running, certbot updates introduce breaking changes, or file permissions on /etc/letsencrypt prevent the client from writing new certificates or renewing existing ones. Sometimes, rate limits are hit during frequent renewal attempts, or firewall rules block the ACME challenge server from reaching your host.
  • Missing or Ignored Renewal Notifications: For commercial certificates, renewal reminders are sent via email. If these go to a generic admin@ or security@ address that isn't regularly monitored, or if the individual responsible has moved roles, the reminders can be missed entirely.
  • Server Clock Skew (NTP Issues): While rarer on well-maintained systems, I've seen servers where NTP (Network Time Protocol) wasn't properly configured or had failed. If the server's clock jumps forward, it can prematurely age certificates. This can be particularly tricky because other systems might function normally.
  • Load Balancer or CDN Certificate Expired: Many modern architectures use load balancers (like AWS ELB/ALB, Google Cloud Load Balancer, NGINX Plus) or CDNs (like CloudFront, Cloudflare) to terminate SSL/TLS. The certificate might be perfectly valid on your origin server, but the certificate configured on the load balancer or CDN has expired. This often catches teams off guard because they're checking the wrong place.
  • Certificate Deployment Process Failure: A new certificate might have been successfully issued, but the process to copy it to the correct location on the web server (e.g., /etc/nginx/ssl/) or to reload/restart the web service (e.g., systemctl reload nginx) failed or was skipped.

Step-by-Step Fix

Solving an expired SSL certificate problem requires a systematic approach. Here's how I typically go about it:

Step 1: Identify the Expired Certificate

First, confirm which certificate is expired and what its expiry date is.

  • Using a Web Browser: Navigate to your website. When the error appears, click on the padlock icon (usually red or crossed out) in the address bar, then "Certificate" or "Connection is not private" -> "Certificate is invalid". Look for the "Valid from" and "Valid to" (or "Expires") dates. This will tell you which certificate the browser is receiving and its expiry.

  • Using openssl (Server-side check): This is my go-to for deeper inspection.
    bash openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates
    Replace yourdomain.com with your actual domain. This command connects to your server on port 443 and extracts the notBefore and notAfter dates from the certificate it receives.

  • Using Certbot (if applicable):
    bash sudo certbot certificates
    This command lists all certificates managed by Certbot on your server, including their domains and expiry dates.

Step 2: Check Server Time

Verify that your server's system clock is accurate.

date
timedatectl

If timedatectl shows NTP service: inactive or the time is significantly off, you have a time-skew issue. Correct it by ensuring NTP is running and synchronized. On most modern Linux systems, sudo timedatectl set-ntp true will re-enable NTP synchronization.

Step 3: Attempt Automated Renewal (if using Certbot/ACME)

If you're using Certbot, try a manual renewal attempt.

sudo certbot renew --force-renewal

The --force-renewal flag is crucial here because certbot renew typically only renews certificates that are within 30 days of expiry. Since it's already expired, you need to force it.

  • Troubleshooting certbot renew failures:
    • Check Certbot logs: sudo less /var/log/letsencrypt/letsencrypt.log
    • Ensure domain's DNS A record points to the server.
    • Check firewall rules: Port 80 (for http-01 challenge) or 443 (for tls-alpn-01 challenge) must be open. If using dns-01 challenge, ensure API keys are valid.
    • Ensure web server (Nginx/Apache) is running and serving files from the .well-known/acme-challenge directory if using webroot authenticator.

Step 4: Manual Renewal/Issuance

If automated renewal isn't an option (e.g., commercial CA, or Certbot is failing persistently), you'll need to manually renew the certificate with your chosen Certificate Authority (CA).

  1. Generate a new Certificate Signing Request (CSR): If you don't have one or if your CA requires a new one.
    bash openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.com.key -out yourdomain.com.csr
    Keep your private key (.key) absolutely secure and private.
  2. Submit the CSR to your CA: Follow your CA's instructions for renewal. They will verify domain ownership (e.g., via email, DNS TXT record, or HTTP challenge).
  3. Download new certificate files: Once validated, the CA will provide your new certificate (e.g., yourdomain.com.crt) and potentially an intermediate/chain certificate file (e.g., chain.crt or ca-bundle.crt).

Step 5: Install and Reload Web Server

Once you have the renewed (or newly issued) certificate and its corresponding private key, you need to install them and ensure your web server uses them.

  1. Copy files: Place the new .crt (and chain.crt if provided) and .key files in the correct directory on your server. Common locations are /etc/nginx/ssl/, /etc/apache2/ssl/, or /etc/letsencrypt/live/yourdomain.com/. Overwrite the old files.
  2. Update web server configuration (if necessary): Verify your Nginx or Apache configuration points to the new certificate and key files.
    • Nginx example:
      nginx ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
    • Apache example:
      apache SSLCertificateFile /etc/letsencrypt/live/yourdomain.com/fullchain.pem SSLCertificateKeyFile /etc/letsencrypt/live/yourdomain.com/privkey.pem SSLCertificateChainFile /etc/letsencrypt/live/yourdomain.com/chain.pem # Often included in fullchain.pem now

  3. Reload/Restart Web Server: This is crucial. Your web server needs to reload its configuration to pick up the new certificate.
    ```bash
    # For Nginx
    sudo systemctl reload nginx
    # Or
    sudo nginx -s reload

    For Apache

    sudo systemctl reload apache2

    Or

    sudo systemctl reload httpd
    `` *Avoid a fullrestartif possible, asreload` often achieves the same goal without dropping active connections.*

Step 6: Verify the Fix

After installation and reload, re-verify the certificate's expiry:

  • Browser: Clear your browser cache and cookies, then visit your website. The padlock should be green, and clicking on it should show a valid expiry date in the future.
  • openssl: Run the openssl s_client command from Step 1 again to confirm the new notAfter date.

Code Examples

Checking the validity dates of a certificate presented by a server:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com </dev/null 2>/dev/null | openssl x509 -noout -dates

Performing a dry run for Certbot renewal (highly recommended before real renewal):

sudo certbot renew --dry-run

Forcing Certbot to renew an already expired certificate:

sudo certbot renew --force-renewal

Reloading Nginx after certificate updates:

sudo systemctl reload nginx

Checking system time:

date
timedatectl

Generating a new private key and Certificate Signing Request (CSR):

openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.com.key -out yourdomain.com.csr

Environment-Specific Notes

The general steps for fixing an expired SSL certificate remain consistent, but implementation details vary significantly across different environments.

  • Cloud Providers (AWS, GCP, Azure):

    • AWS Certificate Manager (ACM): For certificates issued directly by AWS ACM, renewal is typically automatic as long as DNS validation (or email validation if used) remains valid. The problem usually occurs if you imported a third-party certificate into ACM, in which case you are responsible for re-importing a new one. Check the certificate attached to your ELB/ALB, CloudFront distribution, or API Gateway. The console will show expiry dates.
    • GCP/Azure: Similar to AWS, these platforms offer managed certificate services. Always check the certificate configured on your load balancers or edge services. I've seen this when certificates are manually uploaded to a Load Balancer service and the team forgets to update it.
    • Key Takeaway: The certificate expiry might be on the cloud provider's edge service, not your backend server.

  • Docker/Kubernetes:

    • Certificates in Containers: Certificates are often mounted into containers as secrets or volumes. The renewal process must ensure these mounted files are updated, and then the container(s) using them need to be restarted or gracefully reloaded.
    • Kubernetes with Cert-Manager: If using cert-manager for automatic certificate management in Kubernetes, check its logs (kubectl logs -n cert-manager deploy/cert-manager) and Certificate resources (kubectl get certificates). Failures here are often due to incorrect Ingress annotations, DNS challenges failing, or RBAC issues preventing cert-manager from updating secrets.
    • Ingress Controllers: The certificate is often terminated at the Ingress controller (e.g., Nginx Ingress, Traefik). Ensure the secrets referenced by your Ingress resources are up-to-date.

  • Local Development Environments:

    • Self-Signed Certificates: In local dev, you might use self-signed certificates or tools like mkcert. While often given long expiry dates, they can still expire. Browsers usually show warnings for self-signed certs even when valid, so it's easy to miss a genuine expiry.
    • mkcert: If using mkcert, simply running mkcert -install to refresh the local CA and then mkcert yourdomain.test to issue new certs for your dev domains often resolves it.
    • Browser Trust: Ensure your browser trusts your local CA (for mkcert) or that you've explicitly added your self-signed cert to your browser's trust store.

Frequently Asked Questions

Q: Can I just set my server clock back to fix an expired certificate?
A: No, absolutely not. While it might temporarily make the certificate appear valid to your server, it will cause significant issues with other services (e.g., logging, cron jobs, authentication, distributed systems) and your clients will still see the certificate as expired because their clocks are accurate. This is a hack, not a fix, and creates more problems than it solves.

Q: How can I monitor my SSL certificate expiry dates to prevent this in the future?
A: Proactive monitoring is key.
* External Monitoring Services: Many services (e.g., Uptime Robot, StatusCake, Pingdom) can monitor SSL expiry.
* Custom Scripts: You can write a cron job that uses openssl s_client and date to check the expiry and email you if it's within a warning threshold (e.g., 30 days).
* Certbot Hooks: If using Certbot, you can use renewal hooks to trigger notifications or perform health checks.
* Dedicated SRE Tools: Tools like Prometheus with Blackbox Exporter or specialized certificate monitoring tools can integrate into your existing monitoring stack.

Q: Does restarting my web server fix an expired certificate?
A: Only if a new, valid certificate has already been installed but the web server wasn't reloaded to pick it up. If the certificate files themselves are expired, simply restarting the server will not renew them; it will just serve the same expired certificate again.

Q: Why is my website showing an expired certificate for some users but not others?
A: This can be frustrating but typically points to caching or load balancing issues.
* CDN Caching: The CDN might be serving an old, cached certificate, especially if the new one hasn't propagated fully. Purge your CDN cache.
* DNS Propagation: If your domain's A record was recently updated to a new server, some users might still be resolving to the old server which has the expired certificate.
* Load Balancer Nodes: If you have multiple load balancer nodes, one might be misconfigured with the old certificate while others have the new one.
* Browser/ISP Caching: Rarely, a user's local browser or ISP might have aggressively cached the old certificate, though this is less common with modern browser behavior for SSL.

Q: What is the impact of an expired certificate on SEO?
A: Significant. Search engines like Google prioritize secure sites. An expired certificate means your site is inaccessible to users without bypassing dire security warnings. This leads to immediate drops in traffic, high bounce rates, and will inevitably result in your site being penalized in search rankings due to unavailability and poor user experience.