SSL renewal mysterious issue


Today my server went off due to SSL issue (ERR_CERT_DATE_INVALID).

I use a crontab task (once a day) to automatically renew it so I was quite surprised.

I logged into sever and typed certbot certificates to check if my certificates were expired.

Surprisingly, there were not expired : Expiry Date: 2019-02-11 11:17:05+00:00 (VALID: 59 days).

After manual nginx reload it worked back again.

So at that point you might think, “oh, he forgot to have his nginx reload after the crontab renewal”… Well, it is not the case :
30 2 * * * /usr/bin/certbot renew --allow-subset-of-names --noninteractive --renew-hook "/bin/systemctl reload nginx" >> /var/log/le-renew.log

(I took this crontab task from a digitalocean tutorial by the way)

Well, maybe the renew worked but the reload nginx didn’t… however if the renew worked, why is my certificate expiring in 59 days and not in 90 days ?

I have no idea how I can have this situation of suddenly having this SSL error (nobody has access to the server except me and I didn’t access to it for a while).

Do you have any idea on how to figure out what caused this problem so that I can make sure it won’t happen again ?



What’s your domain name?

What’s your web server?

Did you configture the certificate automatically or manually?

Could you please try to run nginx -T and share us the result?

Thank you



I actually mean the uppercase T, which would also print out the virtual hosts configuration and would allow us to help you debug.

By the way, this is moved to #server-config.

Thank you



Well, uppercase T gives:

~# nginx -T
~# nginx: invalid option: "T"

But as I said everything worked great untill today, and nobody accessed the server for more than several weeks.



Do you mind to dig into virtual host files and see if the https virtual host (your domain that have questions) referred to a wrong SSL certificate path?

Thank you


Yes, I’ve just done that. Within nginx config I have :

include snippets/;
include snippets/ssl-params.conf; 

And within :

ssl_certificate /etc/letsencrypt/live/;
ssl_certificate_key /etc/letsencrypt/live/;

(I replaced domain name)

And the output of certbot certificates is:

Found the following certs:
    Certificate Path: /etc/letsencrypt/live/
    Private Key Path: /etc/letsencrypt/live/

Actually the certfile linked behind is cert9.pem so it’s not the first time that I renew and I has been working so far.


The current expiration date being 59 days ahead, it looks to me that actually no renewal was done so far.
But if the certbot renew failed, then why did my server go down, and up again after reload nginx ?
Also why does certbot renew --dry-run gives no error ?



If your browser claimed that the certificate for your API domain is expired, your browser probably have a old cache… (Or i’m connecting to the wrong server)

When i entered your website, your certificate is active and valid.
That’s the same status in OpenSSL.

C:\Users\stevenzhu>openssl s_client -connect -status -ct -CAfile "C:\Program Files\Common Files\SSL\cacert.pem" | openssl x509 -noout -text
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN =
verify return:1
        Version: 3 (0x2)
        Serial Number:
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
            Not Before: Nov 13 11:17:05 2018 GMT
            Not After : Feb 11 11:17:05 2019 GMT
        Subject: CN =
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                RSA Public-Key: (2048 bit)
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
            X509v3 Subject Key Identifier:
            X509v3 Authority Key Identifier:

            Authority Information Access:
                OCSP - URI:
                CA Issuers - URI:

            X509v3 Subject Alternative Name:
            X509v3 Certificate Policies:

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : E2:69:4B:AE:26:E8:E9:40:09:E8:86:1B:B6:3B:83:D4:
                    Timestamp : Nov 13 12:17:05.037 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 29:3C:51:96:54:C8:39:65:BA:AA:50:FC:58:07:D4:B7:
                    Timestamp : Nov 13 12:17:05.139 2018 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
    Signature Algorithm: sha256WithRSAEncryption

Thank you


As stated in the first post, the certificate issue was solved after I systemctl reload nginx.

So I am aware that it is currently valid.

Also it’s not my computer’s cache only because I had two other different people on the globe reporting the same error at the same time.

Let me explain again:
If certbot renew succeeded (and problem was nginx didn’t reload), then why do I still have 59 days left instead of 90 ?
If certbot renew failed or didn’t happen, why do --dry-run gives no error, and why did my my webserver suddenly had ssl error ?


Sorry, I missed this…

I’m sure that the renew does not happen, because normally certbot would renew 30 days in advance…

The renew does not happen because it’s “not the time”, not because some error happened.

Do you happen to have a screenshot / time of that error message?

Thank you


Oh, I see, even after 30 days, it’s still too early to renew ! Well that’s even more mysterious then…
To summarize the facts :

  • Certificates were not close to expiration, everything were fine, nobody accessed the server
  • Despite that, suddenly I had ERR_CERT_DATE_INVALID on chrome, apps using it didn’t work either, I even remember Charles error stating something like “handshake failed” or something.
  • I restart nginx, works again

What did happen ?

(by the way can you replace my domain name from your above console output message please?)


Maybe you have a different automated task that’s also running certbot renew, but without the hook? Like a systemd timer or another scheduled task created by your OS Certbot package?


Right, I think we are getting closer. After thinking through it a lot here’s what I think happened:

  1. As letsencrypt accepts renewal 30 days before expiration, last renewal occured 30 days ago (now 60 days left).
  2. But for some reason the --renew-hook didn’t fire, so nginx didn’t reload
  3. nginx was using the old certificate for 30 days and today it expired

So problem is narrowed down to "renew hook did not happen after successful renewal".

When I look the renewal logs stated in my crontab above, it is full of The following certs are not due for renewal yet messages, but no successful messages ever, despite it successfully renewed many times.

So question is why is the --renew-hook not firing when renew is successful ?

Server : Debian 8.3
Certbot version : 0.10.2

I see that systemctl list-timers outputs certbot.timer… So as you said, somehow I already had a periodic task running through systemd timer … ! How do I fix that ?


Is it just me or is there no --renew-hook option? My certbot client (0.29.1 as of this message) has a --deploy-hook option (which I use, and it works) but no --renew-hook.


The --renew-hook option was also deprecated but it’s definitely present in Certbot 0.10.2. For newer versions of Certbot, the recommended option is --deploy-hook.


You could add the hook to your /etc/letsencrypt/renewal/ file in the [renewalparams] section at the bottom. Then it doesn’t have to be specified as a command line option to certbot renew because Certbot should always detect it automatically.

Otherwise, there should be a file under /etc/systemd/system somewhere that you could delete if you don’t want that timer to run at all. This has been a tricky issue about OS packaging because different OS packagers have different intentions about how to make Certbot perform automated renewal.


How do you keep time sync on your system?


I don’t know, I never thought about that. Is there anything particular to do / know about server time ?


Time sync requires programs that may be specific to your O/S.
But in general, I always sync with NTP.ORG
They keep updated lists of time servers throughout the globe.


Most Linux distributions now use systemd to do time sync for you. You can check its status using:


Example output:

      Local time: Thu 2018-12-13 23:30:20 CET
  Universal time: Thu 2018-12-13 22:30:20 UTC
        RTC time: Thu 2018-12-13 22:30:20
      Time zone: Europe/Paris (CET, +0100)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no