Correct ca bundle to use

[rg305]

@FGasper

depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1

@MikeMcQ

depth=3 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 there are differences in ca-certificates.

[Nummer378]

@FGasper

One anomaly in all of this—which I haven’t seen discussed much—is that OpenSSL 1.0.2 will —by default!—verify LE’s longer chain in connection mode, e.g., with openssl s_client .

So apparently it’s really just the standalone verifications that need to be updated to use trusted-first verification. Thus, even OpenSSL’s own “workaround #2” is inaccurate, as it suggests that s_client needs the trusted-first option to be configured manually.

This depends on how the trust store looks. When DST Root CA X3 is not present in the trust store, OpenSSL 1.0.2 can verify the chain (in real connections) without trusted-first. If DST Root CA X3 is in the trust store, verify-first is needed.

Thus the OpenSSL workarounds are accurate - either fix works. Usually it's easier to remove DST Root CA X3 than enabling trusted-first.

openssl verify somehow behaves slightly differently. I have skimmed through the code but haven't seen an obvious reason why it's different.

[rg305]

Now for my worst case scenario:

openssl version
OpenSSL 1.0.1f 6 Jan 2014

ca-certificates/trusty-updates,now 20170717~14.04.2 all [installed]

# echo | openssl s_client -connect helloworld.letsencrypt.org:443 -servername helloworld.letsencrypt.org | head
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:0
DONE
CONNECTED(00000003)
---
Certificate chain
 0 s:/CN=helloworld.letsencrypt.org
   i:/C=US/O=Let's Encrypt/CN=R3
 1 s:/C=US/O=Let's Encrypt/CN=R3
   i:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
 2 s:/C=US/O=Internet Security Research Group/CN=ISRG Root X1
   i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---

[Nummer378]

Yes, the client-side workarounds all only work for OpenSSL 1.0.2. OpenSSL 1.0.1 neither supports trusted-first, nor the remove-the-old-root workaround.

On the RHEL 6 thread, users have worked to build OpenSSL 1.0.2 for CentOS/RHEL 6 to be able to apply the workarounds. Similar things could be done for other distros, as there's ABI compatibility between 1.0.1 and 1.0.2. It's usually just a matter of recompiling.

Ubuntu has shipped patches for most of their versions (they've also fixed GnuTLS). However because 14.04 is EOL, they did not patch that. 16.04 got backports though.

[HardcoreGames]

NB: IMAP uses 993 for SSL and SMTP uses 587 for SSL, all IMAP servers have been using SSL for a long time

This is what everyone including me use for IMAP and SMTP for Linux based mail which is dominant. dovecot is the standard mail daemon which works with linux.

[MikeMcQ]

@Nummer378

This depends on how the trust store looks.

Yep. Just ran sudo yum update ca-certificates and no longer need -trusted_first for the long chains

Actually, I was launching test EC2's fresh but lately just been stopping / starting for speed. So did not get the update described here:

Correct expired Let’s Encrypt certificate on EC2 instances

I think something in that AWS notice is wrong. The LE ACME servers no longer use the long chain so this is no longer true - right?

Servers with the affected version of OpenSSL and the DST Root CA X3 certificate in their root store can't issue or renew Let's Encrypt certificates.

[sahsanu]

@Nummer378

the client-side workarounds all only work for OpenSSL 1.0.2. OpenSSL 1.0.1 neither supports trusted-first, nor the remove-the-old-root workaround.

Regarding the remove-the-old-root workaround it at least works on Debian 8 (jessie) using OpenSSL 1.0.1t

Cheers,
sahsanu

[eva2000]

@FGasper

cPanel does indeed do an OpenSSL verify prior to certificate installations

That is the fix/change Cpanel is rolling out soon to move away from openssl verify https://forums.cpanel.net/threads/cpanel-33077-letsencrypt-transition-to-isrgs-root-important.673981/post-2880185

@FGasper ah same Felipe at cPanel?

[Nummer378]

@sahsanu

Regarding the remove-the-old-root workaround it at least works on Debian 8 (jessie) using OpenSSL 1.0.1t

Cheers,
sahsanu

I just verified this and this is indeed true.

This seems to be however because of special backports Debian has made to jessie (back when it was still supported). It is not the case on official upstream OpenSSL releases.

[FGasper]

@Nummer378

This seems to be however because of special backports Debian has made to jessie (back when it was still supported).

Of note, CentOS/CloudLinux 6’s default OpenSSL (1.0.1e-fips) also allows trusted-first verification.