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

SSL certificate has expired

Encountering an "SSL certificate has expired" error means your TLS certificate's validity period is over, making your site insecure; this guide explains how to fix it.

What This Error Means

When you or your users see an "SSL certificate has expired" error, it means the digital certificate used to secure the connection to your website or service has passed its validity date. Technically, the notAfter field within the certificate's metadata is in the past. This certificate is crucial for establishing a secure HTTPS connection, ensuring data privacy and integrity between a client (like a web browser) and your server.

From a user's perspective, this error manifests as a stark warning page in their browser, stating that the connection is not private or that the site is insecure. Most modern browsers will block access entirely or present a highly visible warning, deterring users from proceeding. For API endpoints, it means client applications will typically refuse to connect, leading to service outages and integration failures. In my experience, this is one of those errors that will generate immediate support tickets and frantic Slack messages, as it directly impacts user trust and service availability.

Why It Happens

TLS certificates have a limited lifespan for security reasons. Shorter lifespans ensure that if a private key is compromised, it has a limited window of utility for an attacker. It also encourages regular rotation of keys and certificates, which is good security practice.

The core reason an SSL certificate expires is simple: its validity period has ended, and it wasn't renewed or replaced in time. While the concept is straightforward, the underlying causes for why this happens in a production environment can be surprisingly varied and often point to gaps in automation, monitoring, or process. It's rarely malicious, almost always an oversight.

Common Causes

I've seen this in production environments more times than I care to admit, and the root causes usually fall into a few categories:

  • Missed Manual Renewal: For certificates from commercial Certificate Authorities (CAs), the renewal process often involves manual steps: generating a new Certificate Signing Request (CSR), submitting it to the CA, downloading the new certificate files, and then installing them. If these steps aren't explicitly assigned or fall through the cracks during personnel changes or busy periods, expiration is inevitable.
  • Failed Automation (Let's Encrypt/Certbot): Many organizations rely on automated tools like Certbot for Let's Encrypt certificates, which typically renew every 90 days. While highly effective, automation can fail. Common reasons include:
    • Cron Job Failure: The certbot renew command's cron job might stop running due to system changes, permissions issues, or simply being removed.
    • ACME Challenge Failures: If the domain's DNS records change, or if firewall rules block the necessary ports (80 for HTTP-01, 443 for TLS-ALPN-01) for validation, Certbot can't prove domain ownership and renew.
    • Insufficient Disk Space: Less common, but sometimes Certbot can't write its new files.
    • Configuration Drift: The certbot renew command runs successfully, but the web server isn't correctly configured to reload or pick up the new certificate files.
  • Load Balancer/CDN Mismatch: Often, the certificate is correctly renewed on the origin server, but the load balancer (e.g., AWS ALB, GCP Load Balancer, Azure Application Gateway) or Content Delivery Network (CDN) (e.g., Cloudflare) is still serving an old, expired certificate. These services have their own certificate management interfaces that need updating.
  • Monitoring Gaps: A critical oversight is not having robust monitoring in place for certificate expiration dates. You need alerts well in advance (e.g., 30, 14, 7 days before expiration) to give your team enough time to react.
  • Incorrect Deployment: A new certificate might have been generated, but due to a deployment error, an older, expired certificate was accidentally put back in place or the new one wasn't properly linked.

Step-by-Step Fix

Here's how I typically approach fixing an expired SSL certificate, from diagnosis to verification.

1. Identify the Expired Certificate

First, confirm the expiration and identify which certificate is being served.

  • Using a Browser: Navigate to the affected URL. Click on the padlock icon in the address bar (or the "Not Secure" warning), then select "Certificate" or "Connection is secure" -> "More Information". Look for the "Valid From" and "Valid To" (or "Not After") dates.
  • Using openssl (Linux/macOS): This is my go-to for server-side diagnosis.
    bash echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates -subject
    Replace yourdomain.com with your actual domain. This command will output the notBefore (start date) and notAfter (expiration date), along with the certificate's subject. If notAfter is in the past, you have your culprit.

2. Renew the Certificate

The method for renewal depends on how the certificate was originally issued.

  • For Let's Encrypt / Certbot:
    • Log in to the server hosting the website.
    • Run a dry-run first to check for potential issues:
      bash sudo certbot renew --dry-run
    • If the dry-run is successful, proceed with the actual renewal:
      bash sudo certbot renew
    • If certbot renew fails, check the logs (usually /var/log/letsencrypt/) for specific errors. Common issues include firewall blocks, DNS problems, or incorrect web server configuration for the ACME challenge. You might need to temporarily stop your web server (sudo systemctl stop nginx or apache2) and try sudo certbot renew --standalone if using the HTTP-01 challenge.
  • For Commercial CAs (e.g., DigiCert, GoDaddy, Comodo):
    • Go to your CA's portal where you purchased the certificate.
    • Follow their instructions for "reissuing" or "renewing" the certificate. This typically involves generating a new Certificate Signing Request (CSR) on your server:
      bash openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr
      You'll be prompted for domain details. The yourdomain.key is your new private key; keep it secure. The yourdomain.csr is what you submit to the CA.
    • Once the CA processes your CSR, they will provide new certificate files (e.g., yourdomain.crt, ca_bundle.crt). Download these.

3. Install/Update the New Certificate

This step involves telling your web server, load balancer, or other service to use the newly renewed certificate files.

  • Nginx:
    • Copy your new yourdomain.crt and yourdomain.key (and ca_bundle.crt if provided, often concatenated with your domain cert) to their designated secure location (e.g., /etc/ssl/certs/).
    • Update your Nginx configuration block (/etc/nginx/sites-available/yourdomain.conf or similar):
      ```nginx
      server {
      listen 443 ssl;
      server_name yourdomain.com;
      ssl_certificate /etc/ssl/certs/yourdomain.crt;
ssl_certificate_key /etc/ssl/private/yourdomain.key;
ssl_trusted_certificate /etc/ssl/certs/ca_bundle.crt; # Optional, for full chain
# ... other SSL settings and server config

      }
      * Test the Nginx configuration and reload:bash
      sudo nginx -t
      sudo systemctl reload nginx
      * **Apache:** * Copy your new certificate files to their locations (e.g., `/etc/ssl/certs/`, `/etc/ssl/private/`). * Update your Apache virtual host configuration (e.g., `/etc/apache2/sites-available/yourdomain-ssl.conf`):apache

      ServerName yourdomain.com
      SSLEngine on
      SSLCertificateFile /etc/ssl/certs/yourdomain.crt
      SSLCertificateKeyFile /etc/ssl/private/yourdomain.key
      SSLCertificateChainFile /etc/ssl/certs/ca_bundle.crt # For intermediate certs
      # ... other SSL settings and server config

      * Test the Apache configuration and reload:bash
      sudo apachectl configtest
      sudo systemctl reload apache2 # or httpd for RHEL-based systems
      ```
      * Load Balancers (AWS ALB, GCP, Azure):
      * Navigate to the certificate management service (e.g., AWS Certificate Manager (ACM), GCP Certificate Manager).
      * Upload the new certificate files (public key, private key, certificate chain).
      * Update the listener rule on your load balancer to point to the newly uploaded certificate. This is a common step I've seen teams miss, even after renewing the certificate on the origin.

4. Verify the Installation

After installing the new certificate, always verify:

  • Browser Check: Open your website in an incognito or private browser window to avoid caching issues. Ensure the padlock icon is green/closed and no warnings appear. Check the certificate details again to confirm the new notAfter date.
  • openssl Verification:
    bash echo | openssl s_client -servername yourdomain.com -connect yourdomain.com:443 2>/dev/null | openssl x509 -noout -dates -subject
    Confirm the notAfter date is now in the future.
  • Online SSL Checkers: Tools like SSL Labs' SSL Server Test (ssllabs.com/ssltest/) provide a comprehensive analysis of your server's SSL configuration, including certificate validity, chain issues, and supported protocols/ciphers. This is an excellent final sanity check.

Code Examples

Here are some concise, copy-paste-ready commands:

Check Certificate Expiration:

# Check certificate date from a remote server
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null | openssl x509 -noout -dates -subject

# Check a local .crt file
openssl x509 -in /etc/ssl/certs/yourdomain.crt -noout -dates -subject

Renew Let's Encrypt Certificate (Certbot):

# Dry run for testing renewal without making changes
sudo certbot renew --dry-run

# Execute actual renewal
sudo certbot renew

Generate a new CSR and Private Key:

# Generates a new 2048-bit RSA private key and a CSR
openssl req -new -newkey rsa:2048 -nodes -keyout yourdomain.key -out yourdomain.csr

Nginx Configuration Snippet:

# Update paths to your new certificate and key
server {
    listen 443 ssl http2;
    server_name www.example.com example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    # Other SSL settings...
}

Reload Nginx after updating config:

sudo nginx -t && sudo systemctl reload nginx

Apache Configuration Snippet:

# Update paths to your new certificate and key
<VirtualHost *:443>
    ServerName www.example.com
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/example.com.crt
    SSLCertificateKeyFile /etc/ssl/private/example.com.key
    SSLCertificateChainFile /etc/ssl/certs/ca_bundle.crt # Optional, if your CA provides one
    # Other SSL settings...
</VirtualHost>

Reload Apache after updating config:

sudo apachectl configtest && sudo systemctl reload apache2 # For Debian/Ubuntu
# sudo apachectl configtest && sudo systemctl reload httpd # For RHEL/CentOS

Environment-Specific Notes

The general principles remain the same, but the implementation details vary significantly across different environments.

  • Cloud Providers (AWS, GCP, Azure):
    • AWS: Certificates are often managed via AWS Certificate Manager (ACM). For certificates issued by ACM, renewal is typically automated. The catch is ensuring your Elastic Load Balancers (ELBs/ALBs), CloudFront distributions, or API Gateways are configured to use the latest ACM certificate. You might need to manually update the listener rules or distribution settings even if ACM renews the cert. For imported certificates, you must re-import the renewed certificate into ACM.
    • GCP: Google Cloud's Certificate Manager and Load Balancers handle certificates. Similar to AWS, you'd upload renewed certificates to Certificate Manager and ensure your load balancer frontends are updated to reference the new version.
    • Azure: Certificates are managed in Azure Key Vault or directly associated with Application Gateways or App Services. If storing in Key Vault, you'd upload the renewed certificate there, and then ensure linked services are configured to fetch the latest version. For App Services, it's a direct upload.
  • Docker/Kubernetes:
    • In Dockerized environments, certificates are often mounted into containers as files. You'll need to replace the old certificate files in the host directory (or Docker volume) that's being mounted, then restart or redeploy the container.
    • In Kubernetes, certificates are typically stored as Secret objects. For manual renewals, you'd update the tls.crt and tls.key within the secret, then restart the relevant Pods that consume this secret. Many Kubernetes deployments use cert-manager with Let's Encrypt, which fully automates the renewal process. If a cert-manager certificate expires, investigate its logs for ACME challenge failures. I've seen this when a DNS record for an Ingress changed or when a network policy blocked cert-manager from reaching external ACME servers.
  • Local Development:
    • For local development, an expired certificate might be a self-signed one or a temporary one generated by a tool like mkcert. Browsers will still show warnings. The fix is usually to regenerate the self-signed certificate or rerun the mkcert command. It's less critical here, but still annoying.

Frequently Asked Questions

Q: How often do SSL/TLS certificates expire?
A: This varies. Let's Encrypt certificates are valid for 90 days. Commercial certificates (EV, OV, DV) typically last 1 or 2 years, though 3-year options are becoming rarer. It's essential to check the notAfter date for your specific certificate.

Q: Will my website be completely down if the certificate expires?
A: Your web server will continue to run, but browsers and most applications will refuse to establish a secure connection, effectively making your site or API endpoint inaccessible to users and clients. Users will see severe security warnings, and automated systems will return connection errors.

Q: Can I use my old Certificate Signing Request (CSR) to renew my certificate?
A: While some CAs allow re-keying with an old CSR, it's generally best practice and often a requirement to generate a new CSR and private key pair for each renewal. This ensures you're rotating your cryptographic keys regularly, enhancing security.

Q: What should I do if certbot renew keeps failing?
A: Check the Certbot logs, usually located in /var/log/letsencrypt/. Common issues include firewall rules blocking ports 80 or 443, incorrect DNS configuration, or your web server not being properly configured to serve the ACME challenge. Temporarily stopping the web server and trying certbot renew --standalone can sometimes bypass web server-specific issues during the challenge.

Q: Does an expired SSL certificate affect SEO?
A: Absolutely. Google and other search engines prioritize secure (HTTPS) websites. An expired certificate causes browsers to flag your site as insecure, leading to user warnings, increased bounce rates, and a significant negative impact on your search engine rankings. It's crucial to fix promptly.