Wrong date of certificate, letsencrypt serves that instead of the last count number

Hello, I am a facing the following problem: letsencrypt serves older certs, as they have wrong dates (they are in the future). Even though letsencrypt seem to use the last count number (command certbot certificates), it does not actually send this one. I might have messed around some time ago, but I am not quite sure what I did (might have deleted - certbot delete - and recreated). What to do?

My domain is: mail.mindglue.io

I ran this command: sudo certbot certificates

It produced this output:
Certificate Name: mail.mindglue.io
Serial Number: 3733da6036785a3709f19bda33c352cef3a
Key Type: RSA
Domains: mail.mindglue.io
Expiry Date: 2024-04-04 16:23:03+00:00 (VALID: 47 days)
Certificate Path: /etc/letsencrypt/live/mail.mindglue.io/fullchain.pem
Private Key Path: /etc/letsencrypt/live/mail.mindglue.io/privkey.pem

I ran this command: sudo ls -l /etc/letsencrypt/live/mail.mindglue.io/
It produced this output:
lrwxrwxrwx 1 root root 41 Jan 5 17:23 cert.pem -> ../../archive/mail.mindglue.io/cert14.pem
lrwxrwxrwx 1 root root 42 Jan 5 17:23 chain.pem -> ../../archive/mail.mindglue.io/chain14.pem
lrwxrwxrwx 1 root root 46 Jan 5 17:23 fullchain.pem -> ../../archive/mail.mindglue.io/fullchain14.pem
lrwxrwxrwx 1 root root 44 Jan 5 17:23 privkey.pem -> ../../archive/mail.mindglue.io/privkey14.pem

I ran this command: sudo ls -l /etc/letsencrypt/live/mail.mindglue.io/
It produced this output (only fullchain part, others are similar):
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain1.pem
-rw-r--r-- 1 root root 5595 May 27 2023 fullchain10.pem
-rw-r--r-- 1 root root 5518 Jul 27 2023 fullchain11.pem
-rw-r--r-- 1 root root 5518 Sep 6 17:56 fullchain12.pem
-rw-r--r-- 1 root root 5518 Nov 6 05:22 fullchain13.pem
-rw-r--r-- 1 root root 5518 Jan 5 17:23 fullchain14.pem
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain2.pem
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain3.pem
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain4.pem
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain5.pem
-rw-r--r-- 1 root tomcat 5596 Nov 20 2022 fullchain6.pem
-rw-r--r-- 1 root root 5595 Nov 28 2022 fullchain7.pem
-rw-r--r-- 1 root root 5595 Jan 27 2023 fullchain8.pem
-rw-r--r-- 1 root root 5595 Mar 28 2023 fullchain9.pem

My web server is (include version):Apache/2.4.56 (Debian)

The operating system my web server runs on is (include version): Debian GNU/Linux 11 (bullseye)

My hosting provider, if applicable, is:

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): No

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 1.12.0

@Oupat , welcome to the community!

I see no problem with your certificate. It is normal that the certificate expiry date is in the future. It means that the certificate is not yet expired, it is usable.

Certificate chain
 0 s:CN = mail.mindglue.io
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan  5 16:23:04 2024 GMT; NotAfter: Apr  4 16:23:03 2024 GMT

You may see that we are at this moment in the validity period of that certificate.

If you get warning please check the date on the client device, isn't the time set earlier than 5th of January 2024?

4 Likes

it's imap server doesn't use renewed certificate but old one:

PS C:\Users\tjtnc> openssl s_client -connect mail.mindglue.io:993
Connecting to 51.75.243.43
CONNECTED(000001E8)
depth=2 C=US, O=Internet Security Research Group, CN=ISRG Root X1
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=1 C=US, O=Let's Encrypt, CN=R3
verify return:1
depth=0 CN=mail.mindglue.io
verify error:num=10:certificate has expired
notAfter=Feb 4 04:22:16 2024 GMT
verify return:1
depth=0 CN=mail.mindglue.io
notAfter=Feb 4 04:22:16 2024 GMT
verify return:1

4 Likes

That might be due to either misconfiguration of the IMAP server or it just requiring a reload.

3 Likes

Thank you very much, it indeed needed a reload.

4 Likes

You can add that reload as a --deploy-hook so it runs automatically every time you obtain a new certificate.

3 Likes

A --deploy-hook would be a better idea. There's no such option as --post-deploy-hook in Certbot :wink:

2 Likes

Thanks. Corrected. Always RTFM instead of relying on faulty organic memory. :smirk:

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.