Fix NET::ERR_CERT_DATE_INVALID: Why Let’s Encrypt Failed to Auto-Renew

The ProblemNothing kills user trust faster than a giant red "Your connection is not private" warning. You see the NET::ERR_CERT_DATE_INVALID error when a browser realizes your SSL certificate has expired or isn't valid yet. Let’s Encrypt certificates are valid for 90 days. Certbot usually attempts a renewal at the 60-day mark, but if that process hits a snag for 30 days straight, your site eventually goes dark.

When visitors land on your page, they are blocked by this specific browser flag:

NET::ERR_CERT_DATE_INVALID

TL;DR: The Emergency RescueIs your site down right now? Force a manual renewal and kick your web server to apply the new files:

# Try to renew all certificates immediately
sudo certbot renew

# Reload your web server to pick up the new .pem files
sudo systemctl reload nginx  # Use 'apache2' if on Apache

If certbot renew throws an error instead of saying "Congratulations," you have an underlying configuration issue.

Why Auto-Renewal Usually Fails### 1. The "HTTPS-Only" Trap (Port 80 is Closed)Certbot’s HTTP-01 challenge is the most common validation method. It needs to place a temporary file in .well-known/acme-challenge/ and reach it over port 80. Many admins close port 80 thinking they only need 443 for HTTPS, but Let's Encrypt still needs port 80 to verify you own the domain.

2. The Ghost in the RAM (Missing Hooks)Success on disk doesn't always mean success in the browser. Certbot might save a shiny new certificate to /etc/letsencrypt/live/, but Nginx keeps the old, expired certificate cached in memory. If you don't tell Nginx to reload, it will keep serving the dead certificate until the process restarts.

3. DNS DisconnectsDid you migrate to a new VPS last month? If your A or AAAA records point to an old IP address, the Let's Encrypt validation server will look in the wrong place. The renewal will time out or return a 404 error.

4. Silent Cron FailuresMost Linux distributions use a systemd timer to check for renewals twice a day. If a package update masked this timer or corrupted the crontab, the automation simply stops running without ever sending you an alert.

Step-by-Step Troubleshooting### Step 1: Check the Real Expiry DateDon't trust the browser cache. Pull the dates directly from your server's certificate:

openssl s_client -connect yourdomain.com:443 -servername yourdomain.com | openssl x509 -noout -dates

Look at the notAfter line. If that date is in the past, your renewal definitely didn't trigger.

Step 2: Audit Your FirewallEnsure port 80 is wide open to the public. If you use UFW on Ubuntu, check your status:

sudo ufw allow 80/tcp
sudo ufw reload

If you're on AWS, double-check your Security Groups. You need an Inbound Rule for HTTP (80) from source 0.0.0.0/0.

Step 3: Run a Debugging Dry RunThe --dry-run flag is your best friend. It simulates the renewal without hitting Let's Encrypt's strict rate limits:

sudo certbot renew --dry-run

Watch the output for these specific red flags:

• "Timeout during connect": Your firewall is likely still blocking port 80.- "404 Not Found": Your Nginx root directive might be pointing to the wrong directory for challenges.- "DNS problem: NXDOMAIN": Your domain isn't resolving correctly.### Step 4: Clean Up Your Nginx ConfigEnsure your port 80 server block isn't accidentally blocking hidden folders. A standard, Certbot-friendly config looks like this:

server {
    listen 80;
    server_name yourdomain.com;

    location /.well-known/acme-challenge/ {
        root /var/www/html;
    }

    # Redirect everything else to HTTPS
    location / {
        return 301 https://$host$request_uri;
    }
}

Step 5: Set and Forget with Post-HooksTo ensure the NET::ERR_CERT_DATE_INVALID error never returns, automate the server reload. You can add a --deploy-hook, which only runs if a renewal actually succeeds. This is more efficient than a post-hook that runs every time the timer checks.

sudo certbot renew --deploy-hook "systemctl reload nginx"

This command updates your renewal configuration file in /etc/letsencrypt/renewal/ automatically.

Verifying the FixAfter a successful renewal, use curl to verify the new expiration date from the command line:

curl -vI https://yourdomain.com 2>&1 | grep -i "expire date"

Finally, make sure the systemd timer is actually scheduled to run again:

systemctl list-timers | grep certbot

If you see a future date under the "NEXT" column, you're all set. Your certificates will now stay fresh without manual intervention.

Final ChecklistSSL errors are almost always caused by broken automation rather than the certificate itself. By keeping port 80 open and using deployment hooks, you can keep your site green and secure indefinitely.