How can I tell if my letsencrypt is good to go for Sept 30th

[rtkluttz]

I am confused how to tell if my letsencrypt SSL is good to go. I'm getting conflicting info.

When I use Firefox to my zimbra webmail, it shows that I am still using the root cert that will die. But ssllabs shows both DST Root CA X3 AND ISRG Root X1. Can I relax, am I ready?

Selection_125.jpg (146.71 KiB) Viewed 2109 times

[ianw1974]

Easier would be to click the padlock icon in Firefox to the left of the url and view the certificate info here, since when I do it for my servers with Lets Encrypt, it shows the expiry dates. That way, you can see if the certificate is due to expire 30 September 2021 or not. If it is, then it means yours is still using the old one. If you have a date after September 30, then everything would be OK.

[rtkluttz]

Well that is actually what has me concerned. Firefox shows DST Root CA X3 is being used with expiry of Sept 30th.

But does that actually mean its expiring or is it some weird type of nested certs and will fail over to the newer ISG one that the ssllabs is reporting?

[ianw1974]

Would be worthwhile checking your renewal process that you utilise with Zimbra to see if it's renewing the certificates correctly. And do you have a hook to run afterwards to restart Zimbra so that it starts using the new cert? I don't use LE with Zimbra, but I do use it with other things, Gitlab for one, which picked up and updated only a day or two ago from what I see.

[JDunphy]

It should be fine. For old android devices (I mean really really old android devices), some admins will still use the older chain even if the trust anchor has expired because there is no way to update those older clients unless done manually. This solution works because Android intentionally does not enforce the expiration dates of certificates used as trust anchors. This is discussed in the ref link below but came from: https://letsencrypt.org/2020/12/21/exte ... ility.html

Note: use openssl with -show-chain (need newer openssl 1.1.1 and above) described in the forum post below to see what you have if these other methods have you confused with how your cert was generated and signed. It doesn't really matter which letsencrypt acme client you used. You need your certificate and the last argument you provided the zimbra zmcertmgr command to verify the certificate.

For example... here is the 3rd argument provided to zmcertmgr:

Code: Select all

# su - zimbra
% cd .acme.sh/mail.example.com
% zmcertmgr verifycrt comm mail.example.com.key mail.example.com.cer ca.cer.real

So we would show the chain like this:

Code: Select all

# su - zimbra
% cd .acme.sh/mail.example.com
% openssl version
OpenSSL 1.1.1k FIPS 25 Mar 2021
% openssl verify -show_chain -purpose sslserver -CAfile ca.cer.real mail.example.com.cer
/opt/zimbra/.acme.sh/mail.example.com/mail.example.com.cer: OK
Chain:
depth=0: CN = mail.example.com (untrusted)
depth=1: C = US, O = Let's Encrypt, CN = R3
depth=2: C = US, O = Internet Security Research Group, CN = ISRG Root X1

Lastly, zmcertmgr uses the command line tool openssl for its chain validation and verification. To make things odder, they uses a perl module (library) to verify the certificate on ldap start at runtime so they have us covered with different software doing the same thing.

Ref: viewtopic.php?f=15&t=60781&start=110#p301489

HTH,

Jim