@criton2000
hmm... pfx...
Then you are using Windows; And it probably doesn't have the "ISRG Root X1" in the trusted store.
[and possibly not even the "R3" intermediate (not actually required)]
And Windows is doing w/e it feels like with that included information (nothing).
Try adding the "ISRG Root X1" cert to the trust store.
[might need a reboot and/or rebinding of IIS to the cert]
You can find it here: Self-signed: der, pem
Port 25 didn't give a reply. On Port 465 I got this:
CONNECTED(00000003)
Didn't find STARTTLS in server response, trying anyway...
write:errno=0
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 346 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
Wait, I don't understand. DST CA X3 is the retired root cert, right? How is that preferred? I need help understanding this. ISRG Root X1 is the one we need to add to some services that can't connect anymore...
As I represent some websites, and we can't just tell potential website visitors to upgrade software that simply isn't upgrade-able (mac mavericks will never go past chrome 67, for example)
so, we must use a different certificate with a root certificate that is universally trusted... (any ideas?)
if you are using certbot as an ACME client to get LE certificates, you can change the ACME server to use a different provider, I'm still in the process of looking into this (sslforfree.com via zerossl.com)
I believe the ACME protocol requires free 90 day certs, and zerossl does offer that, apparently...) User Guide β Certbot 1.19.0.dev0 documentation
Thank you for your help.
No. I developed on windows (hence I have to use pfx, otherwise I cannot try), but production server is Ubuntu 18.04, where I commented DST CA X3 using sudo dpkg-reconfigure ca-certificates
I am not using IIS nor ngnix, but embedded web server kestrel.
Now I executed openssl s_client -connect hub1.cet.cloud:443 -servername hub1.cet.cloud
on an Ubuntu 20.04 PC, with same result (here /etc/ca-certificates.conf contains DST CA X3 commented, and ISRG Root X1 listed and enabled).
Perhaps I am misunderstanding: when requesting certificates using "openssl s_client", does server answers with complete chain (teorically)? Can we see complete response some way?
No, it uses another file, freecert.pfx, produced with command openssl pkcs12 -inkey /etc/letsencrypt/live/hub1.cet.cloud/privkey.pem -in /etc/letsencrypt/live/hub1.cet.cloud/fullchain.pem -export -out freecert.pfx -password pass:[mypassword]
@criton2000
Well then is is having issues with the PFX file (or contents therein) or is unable to match the chain entries to whichever root store it uses.
It fails to serve the provided chain.
[mind of its' own]
Our domains have been affected by the DST Root CA X3 expiration.
The only solution we found was to update certbot to at least 1.12 to have access to the --prefered-chain command to force ISRG Root X1.
The problem is that certbot only goes up to 0.31 with apt.
We tried snapd but it seems to not be compatible with our Ubuntu 16.04 (error: system does not fully support snapd: cannot mount squashfs image using "squashfs": mount: unknown filesystem type 'squashfs')
Same goes for pip installation, which shows errors that seems to be linked to our python version.
Any help would be appreciated to update our certbot version, like many others, our system is down and clients are waiting.
Welcome to the community forum! Yes, there are several working and specific solutions that many posters have adopted to resolve issues client side. However the specific solution depends on which of the two expirations are causing you problems and what your set-up is like.
In this thread, many users have discovered they are sending an incorrect chain or no chain at all. The solution is to update the configuration specific to your server to serve the correct the chain. You can use the search field on this thread or in the forum generally to see if information has posted and resolved for your server.
The other problem is around which chain you are sending particularly for the roots. There are trade-offs for each one and you can read about them here under the RSA changes for May 4th Production Chain Changes
Those are the main server side options you can take to still use Letβs Encrypt. There are some client side problems related to cached certificates and chain building behavior that have specific solutions as well.
Please begin by searching on the forum to see if your specific setup has been asked about. If you cannot find it, you will need to include some basic information like what is running server-side, what problem you are seeing, and your domain.