OpenSSL/Browser still showing 'Certificate Exipred' after renwal by certbot

Help
1

Hello,

i got the problem, that the renewal of the letsencrypt-certificate went well and i do see the new certificate, while attempting a connection via openssl. But openssl (as the browser) still complains, that the certificate has expired.

Certbot found, that the present certificate was not due to renewal, so i did a forced renewal. This went well again, but the result ist still the same: crtificate expired for browser and openssl.

I have no clue why. Any hint is much appreciated!

Cheers, Georg

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: api.frankfurthistory.app

I ran this command:
openssl s_client -connect api.frankfurthistory.app:443

It produced this output:
CONNECTED(00000005)
depth=1 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT

Then i tried:
certbot renew

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log

Processing /etc/letsencrypt/renewal/api.frankfurthistory.app.conf

Certificate not yet due for renewal

The following certificates are not due for renewal yet:
/etc/letsencrypt/live/api.frankfurthistory.app/fullchain.pem expires on 2023-04-04 (skipped)
No renewals were attempted.

I restarted the apache several times, and after that i get the new certificate persented when i connect via openssl, still it is complaining, that the certificate has expired.

My web server is (include version):

Apache apache2 2.4.38-3+deb10u7

The operating system my web server runs on is (include version):

debian/expat 2.2.6-2+deb10u1 in a docker-container

My hosting provider, if applicable, is:

hetzner.com

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.32.2

2

I already found in this forum, that i should not have done a force renewal. I followed some advice a found on a website (stackoverflow maybe) I will not do that again.

2 Likes
3

Welcome to the community @Georglange

I see that domain using HTTPS uses the current cert although Apache is not configured properly and the chain has a duplicate leaf cert. See this SSL Checker (link here) and SSL Labs (link here)

If you show us the SSLCertificate... lines in your Apache VirtualHost we can advise better

That said, is your problem just that message from openssl? Or, is there some other real problem and you just tried openssl to check it?

FWIW, here's my openssl result:

openssl s_client -connect api.frankfurthistory.app:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = api.frankfurthistory.app
verify return:1
---
Certificate chain
 0 s:CN = api.frankfurthistory.app
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb  7 10:41:08 2023 GMT; NotAfter: May  8 10:41:07 2023 GMT
 1 s:CN = api.frankfurthistory.app
   i:C = US, O = Let's Encrypt, CN = R3
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Feb  7 10:41:08 2023 GMT; NotAfter: May  8 10:41:07 2023 GMT
 2 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Sep  4 00:00:00 2020 GMT; NotAfter: Sep 15 16:00:00 2025 GMT
 3 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
   a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA256
   v:NotBefore: Jan 20 19:1
4 Likes
4

This is what I see with Windows 10 Firefox 109.0.1 (64-bit)

image
image1014Ɨ887 9.1 KB

2 Likes
5

@Bruce5051 , @MikeMcQ
Thank you for your time and knowledge!

I feel a little bit embarrassed now. Yes this has been a 'real' problem, as neither the app-users, nor the browsers of the backend-users could connect, because of this expired certificate.
I used opensssl on my console to check, what is coming from the server. But it seems, my Firefox and my openssl 'lied' to me, as there where already users connecting to the server whilst i had been looking at the 'expired'-messages, both in browser and console. :confused:

The problem with docker is, that certbot cannot reach into the directory, where apache inside the
container is looking for the certificates. I copied the certificate-files while seting up the environment. And the renewal by certbot worked fine, only the certificates had not been copied to the right dir again.

I think, for the future i will set up a cron-job to copy the files after they are renewed and restart apache afterwards.

Again, thank you! This problem does not longer exist and this thread can be marked as solved (if the chain-issue is not that problematic).

The only thing i am still a bit worried about is: why did openssl come back with an expired-error when elsewhere everything had already been fine?

And i do not know, if this 'chain-issues' are a serious issue there, as this is only one 'flavour' of several apps, which are running on the same production-environment on different IPs/domains without any problems by now.

Cheers, Georg

3 Likes
6

You can mark any of the posts as the Solution from the bottom menu in each post

What openssl version is it? It might just be an old one that reports it that way. Although, I checked with openssl 3.0.2 and a 1.0.2k and neither reports like that.

Was that the entire openssl output related to the cert and chain? (don't need to see the actual cert) Because usually each step of the chain is shown and that DST cert in the chain is not usually depth 1.

It might be related to how your openssl is handling the extra leaf cert which you should remove

Note there is an expired cert in the chain (DST Root CA X3) which is for compatibility for older Android devices. It is included in the default chain from Let's Encrypt. In fact, this website even uses that default chain. It's possible this could cause problems with certain clients and you could consider the "short chain" instead.

Certbot can return the short chain with the --preferred-chain "ISRG Root X1" option.

More info on these chains is here:

4 Likes
7

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