Questions re: OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates

This is a great news to me. Thank you!

Our system have some technical concerns for update openssl from 1.0.2 to 1.1.0.

On the other hand, We have found that openssl 1.0.2 has a flag (X509_V_FLAG_TRUSTED_FIRST) which can verify certificate from trusted ca store first.
The following is the certificate chain used in our experiment environment

a (expired) -> b (cross sign) -> c -> d (simulate Android Compatible Chain)
b (self sign) -> c -> d (simulate Openssl 1.0.2 Compatible Chain)

Server Provide certificate chain: a (expired) -> b (cross sign) -> c ->d

Client use openssl 1.0.2 can successfully verify the new chain when X509_V_FLAG_TRUSTED_FIRST is enabled and certificate b (self sign) is within system ca store.

We would like to know wheterh is it recommend to open this flag at openssl 1.0.2?

4 Likes

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

Last year when ADDTrust expired we have openssl issue of 1.1.x.
Check details below at " Condition 2 - Broken Clients - Known Examples ( OpenSSL based client software )":
https://calnetweb.berkeley.edu/calnet-technologists/incommon-sectigo-certificate-service/addtrust-external-root-expiration-may-2020#affected

But I saw message that you are compatible with openssl 1.1.x without problem. Could you help confirm is that really true?
Because last year, we have manually remove expired CA from server and execute update-ca-certificates on Debian 9 to mitigate the issue.

2 Likes

I am still struggling to understand what was fixed in OpenSSL and in GnuTLS.

Is the OpenSSL change this one?

And the GnuTLS change is it this one?

And related merge-requests?

I am slightly concerned that the default chain will be changed to the one that "helps android" whilst at the same time "kill Linux which are already trusting ISRG Root X1"

Are you already operating demo sites with the longer / next default chain, in the similar fashion to badssl.com? Such that we can test our clients against them?

1 Like

These clients used to verify certificate chains in a bad way, here's a short explanation:

Older versions of OpenSSL, GnuTLS (+ many others, e.g LibreSSL) basically validate a certificate chain by walking up the chain as send by the server, then searching the trust store for the "highest" certificate. That means those clients always validate up the highest certificate in the chain.

This is an issue, as Let's Encrypt is going to send a chain that ends with DST Root CA X3, which expires later this year. This means that those clients will fail, as they no longer consider the highest root a trusted certificate.

The correct way to verify the certificate chain is by looking at the intermediates: In the chain send by Let's Encrypt certificates, there's an intermediate "ISRG Root X1 signed by DST Root CA X3" that is in fact a root in itself. If a chain verifier realizes this, it can stop verifying at ISRG Root X1 and does not need to verify the expired DST Root CA X3 cert.

Older versions of many non-browser verifiers sadly do not have this feature, and will sadly fail handshakes.

The OpenSSL fix to this issue was the introduction of a new flag X509_V_FLAG_TRUSTED_FIRST. If a client application sets this flag, it causes OpenSSL to search the trust store before processing the intermediate. This causes OpenSSL to stop looking at the chain when ISRG Root X1 is encountered, preventing issues with an expired DST Root CA X3.

This flag is available since OpenSSL 1.0.2 (must be manually requested by the application using OpenSSL) and is set by default since OpenSSL 1.1+, which is why that version is considered fixed.

Yes, altough the initial description is highly confusing.

Let's Encrypt has already started to use the new chain (since May 4), but it isn't causing issues yet, as DST Root CA X3 is not yet expired. You can't test using production, as Let's Encrypt certificates are only valid for 90 days, but the expiry is more than 90 days away.

You can however test using the staging enviroment, quoting myself:

6 Likes

Debian 9 does not ship OpenSSL 1.1 by default (but it does ship 1.0.1, which is a similar number), are you running custom versions of OpenSSL? Are you certain you had 1.1 when you had issues? Yeah, confused jessie and stretch.

I did testing with OpenSSL 1.1.1 earlier this year and it handled the new chain (more specifially: A test replica of the new chain) just fine. It did not matter if the expired CA was in the trust store, as it wasn't used for validation anyway.

I remember that some Python version had an issue that caused it to fail when an expired Root CA was present in the trust store, but I don't remember enough details to make a conclusion.

2 Likes

@Nummer378 :
Debian 9 does not ship OpenSSL 1.1 by default (but it does ship 1.0.1, which is a similar number), are you running custom versions of OpenSSL? Are you certain you had 1.1 when you had issues?

Debian 9 currently have OpenSSL 1.1.0l (check [stretch] part, not jessie ).
https://packages.debian.org/search?keywords=openssl

I'm also not sure which was the fixed version of OpenSSL. But I've experienced the broken certificate chain because of expiration last year in Debain Stretch. And from https://popcon.debian.org/ , Debian Stretch still have a lots of online machine. It will be helpful if you can confirm OpenSSL 1.1.0* in Debian Stretch will be fine this time. Or if you can give me some guide, I can also help confirm that.

I can onfirm Debian 10(which shipped 1.1.1 by default) will be fine when expired CA in the trust store.

Thank you.

1 Like

From my point of view (also see my post above), the fix was the introduction of X509_V_FLAG_TRUSTED_FIRST in OpenSSL. Per the official documentation, this flag is set by default since OpenSSL 1.1.0. The docs don't say if they mean 1.1.0 in general, or a specific patch release of 1.1.0.

https://www.openssl.org/docs/manmaster/man3/X509_VERIFY_PARAM_set_flags.html

When X509_V_FLAG_TRUSTED_FIRST is set, which is always the case since OpenSSL 1.1.0, construction of the certificate chain in X509_verify_cert(3) searches the trust store for issuer certificates before searching the provided untrusted certificates. Local issuer certificates are often more likely to satisfy local security requirements and lead to a locally trusted root. This is especially important when some certificates in the trust store have explicit trust settings (see "TRUST SETTINGS" in openssl-x509(1)).

Edit: I just checked the source code. X509_V_FLAG_TRUSTED_FIRST is set by default since Check chain extensions also for trusted certificates · openssl/openssl@0daccd4 · GitHub, which is part of the very first OpenSSL 1.1.0 release.

There's some confusion to this, as you sometimes also need to set X509_V_FLAG_PARTIAL_CHAIN, which is not set by default in 1.1.0, but I believe that this isn't neccessary in this case though.

I also want to highlight that your trust store needs to include ISRG Root X1, otherwise all of this is moot.

2 Likes

I just ran a few tests with a Debian Stretch test VM, default settings.

# cat /etc/os-release
PRETTY_NAME = "Debian GNU/Linux 9 (stretch)"

# wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-x1.pem
# wget https://letsencrypt.org/certs/staging/letsencrypt-stg-root-dst.pem
# cat letsencrypt-stg-root-dst.pem letsencrypt-stg-root-x1.pem > certs-combined.pem

# openssl version
OpenSSL 1.1.0l 10 Sep 2019

Simulating that only ISRG Root X1 is in the trust store:

# openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile letsencrypt-stg-root-x1.pem
-> Verification: OK

Simulating that only DST Root CA X3 is in the trust store:

# openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile letsencrypt-stg-root-dst.pem
-> Verification error: certificate has expired

Simulating that both DST Root CA X3 and ISRG Root X1 are in the trust store:

# openssl s_client -connect expired-root-ca-test.germancoding.com:443 -servername expired-root-ca-test.germancoding.com -verify 1 -verifyCAfile certs-combined.pem
-> Verification: OK
8 Likes

I think it's probably better to think about the situation as a Directed Graph (in the mathematical sense) in which the nodes are named public keys and the edges are certificates issued by one node. The goal of a verifier is to decide if there are a series of edges that lead from named public key they trust (e.g. ISRG Root X1) to the leaf certificate that a TLS server is showing them to prove its identity. In this understanding it is these named keys which are trusted at the root, not certificates for them.

A verifier that trusts ISRG Root X1 never needs to contemplate the "ISRG Root X1 signed by DST Root CA X3" certificate, because this represents an edge between ISRG Root X1 (trusted) and DST Root CA X3 (also trusted but soon to expire) so who cares?

It can stop once it sees just the "R3 signed by ISRG Root X1" certificate, it knows what ISRG Root X1 is, and it can verify using the public key it knows for that name that this certificate is valid, therefore R3 is trustworthy, therefore the leaf certificate is acceptable.

Unfortunately graph traversal problems are hard and so there is software that gets this wrong.

4 Likes

@tialaramex explains it well, though I would a caveat:

I would say "if there is a series of valid edges the lead from the the end entity certificate to any trust anchor (aka root certificate)." In other words, the path builder component of a verifier shouldn't be looking for a specific trust anchor, but for any one for which there's a path.

A couple of good but dense blog posts on the subject:

7 Likes

There are some Ubuntu releases that will be affected by this, whilst they are still supported or under extended security maintenance.

I've open bug reports to start tracking this issue in the affected series for openssl & gnutls28.

https://bugs.launchpad.net/bugs/+bugs?field.tag=letsencryptexpiry

5 Likes

I'm using Certbot to get my certs and it provide as of today:

  • fullchain.pem: leaf <- R3 <- ISRG Root X1
  • chain.pem: R3 <- ISRG Root X1

How will they look in the future?

1 Like

leaf <-R3 <- ISRG Root X1 <- DST root X3 IIRC

3 Likes

When will the change be rolled out - I think I have seen notes about June, but apparently it has not yet taken place?

1 Like

The new "long" chain is in use since May 4.

Your fullchain/chain includes R3, signed by ISRG Root X1 and ISRG Root X1, signed by DST Root CA X3. This is the current and future chain (for the foreseeable future) - no further changes.

4 Likes

I wonder, if between now and 2024 one could change to use a different, non-letsencrypt CA, from someone else that is both trusted by old Linux distros and old Android.

I fear of making a choice if I care more about "openssl s_client 1.0x" versus "android web browser 4.x..7.x". Cause I really don't know which has the largest impact (api usage, versus humans tap tap).

Is there a way to lookup what trust store CAs 4.x android shipped with?

2 Likes

If old client compatibility is your highest concern, another CA is probably your best option.

As Android 4.0+ is ~2012+, they should work fine with Sectigo's roots.

2 Likes

@beautifulentropy can someone else but DST sign ISRG Root X1 ? I.e. In android 7 i see GlobalSign with expiry in 2038, VeriSign until 2038, etc...

2 Likes