How to Fix NET::ERR_CERT_DATE_INVALID (Expired SSL Certificate) on Apache and Nginx

Nothing destroys user trust faster than a massive red warning screen in Google Chrome stating: “Your connection is not private (NET::ERR_CERT_DATE_INVALID)”.

This error strictly means that the SSL/TLS certificate installed on your web server has surpassed its expiration date. Modern browsers refuse to connect to sites with expired certificates to protect users from potential Man-in-the-Middle (MITM) attacks.

If you are hosting your application on a Dedicated Linux Server, you are responsible for maintaining your own certificate lifecycle. Here is the technical breakdown of how to identify the exact expired certificate and renew it on Apache or Nginx.

Step 1: Diagnose the Exact Expiration

Before touching your server config, verify exactly which certificate has expired (sometimes it’s the root CA, not your domain cert, though less common).

You can use curl or openssl directly from your local terminal to inspect the remote certificate chain:

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

The output will show:

notBefore=Aug 10 12:00:00 2026 GMT
notAfter=Nov  8 12:00:00 2026 GMT

If the current date is past the notAfter date, the certificate is definitively expired.

(If your certificate is valid but you are still getting browser warnings, you might be experiencing a Mixed Content Error.)

Step 2: Renewing Let’s Encrypt (Certbot) Certificates

The vast majority of modern websites use free Let’s Encrypt certificates, managed via the certbot utility. By default, these expire every 90 days. If your cron job failed, you must renew it manually.

SSH into your server and run:

sudo certbot renew

If Certbot fails, it is usually because the domain no longer points to the server, or the webroot has changed. You can force a specific plugin (like Nginx or Apache) to attempt renewal:

sudo certbot renew --nginx
# OR
sudo certbot renew --apache

Checking the Auto-Renewal Cron Job

To prevent this from happening again, ensure the certbot renewal timer is active:

sudo systemctl status certbot.timer

It should read active (waiting). If it is inactive, enable it:

sudo systemctl enable --now certbot.timer

Step 3: Installing Commercial SSL Certificates

If you purchased a premium EV or OV certificate (see our SSL Certificates offerings), you cannot use Certbot. You must generate a new CSR (Certificate Signing Request), get it signed by the Certificate Authority, and manually replace the old files.

Once you have your new .crt and .key files, locate your virtual host configuration.

For Nginx:

server {
    listen 443 ssl;
    server_name yourdomain.com;
    
    ssl_certificate /etc/ssl/certs/yourdomain_new.crt;
    ssl_certificate_key /etc/ssl/private/yourdomain_new.key;
    # ...
}

For Apache:

<VirtualHost *:443>
    ServerName yourdomain.com
    
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/yourdomain_new.crt
    SSLCertificateKeyFile /etc/ssl/private/yourdomain_new.key
    # ...
</VirtualHost>

Step 4: Restart the Web Server

A critical step that many sysadmins forget: Nginx and Apache load certificates into memory upon startup. Even if you replace the files on the disk, the server will continue serving the old, expired certificate from RAM until you reload the daemon.

# Nginx
sudo systemctl reload nginx

# Apache (Ubuntu/Debian)
sudo systemctl reload apache2

# Apache (CentOS/RHEL)
sudo systemctl reload httpd

Conclusion

The NET::ERR_CERT_DATE_INVALID error is a severe but easily fixable issue. By understanding how to inspect the certificate chain via OpenSSL, manually triggering Certbot renewals, and ensuring your web server daemon is properly reloaded, you can restore your site’s security and reputation in minutes.

Maintain full control over server SSL certificates with Nextgen’s Pakistan VPS plans.