Extending Android Device Compatibility for Let's Encrypt Certificates

[jo...@letsencrypt.org]

We (Let's Encrypt) just announced a new cross-sign from IdenTrust which is a bit unusual because it will extend beyond the expiration of the issuing root. More details can be found here:

https://letsencrypt.org/2020/12/21/extending-android-compatibility.html

Best,
Josh

[Man Ho (Certizen)]

I'm curious whether this approach of cross-signing from a root
certificate which has already expired is exceptional for Let's Encrypt. 
I'm not aware of any discussion on what conditions this approach could
be accepted by Mozilla and other root certificate programs. Or, is it
just an usual practice of CA? If yes, this approach may provide some new
solutions in the CA ecosystem.

Firstly, for those new CAs who do not have their root certificates
included in the root certificate programs, they may acquire an expired
root certificate from an existing CA who are probably more willing to
sell the expired root certificate rather than an active root certificate.

Secondly, for some CAs whose root certificates are going to expire, they
may continue using the root certificates to issue intermediate CA
certificates beyond its expiry. So, there will be no need for rollover
of root certificates to new one.

Are they good or bad things?

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[Aaron Gable]

As mentioned in the blog post, and as we'll elaborate on further in an
upcoming post, one of the drawbacks of this arrangement is that there
actually is a class of clients for which chaining to an expired root
doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
mode as various clients ran into on May 30th of 2020, when the AddTrust
External CA root expired.

For the sake of public feedback, the following is the profile which we
intend to have the new cross-sign issued with:
* Subject and Subject Public Key Info: Identical to the self-signed ISRG
Root X1 (https://crt.sh/?id=9314791) of course
* Validity: Three years from the date of issuance
* Basic Constraints: CA:TRUE, and no pathlen set (same as self-signed ISRG
Root X1)
* Key Usage: Cert Sign and CRL Sign (same as self-signed ISRG Root X1)
* EKUs: none, as this cross-sign shares the same name and pubkey as an
existing root certificate (BRs 7.1.2.2)
* AIA issuer url: http://apps.identrust.com/roots/dstrootcax3.p7c (same as
R3)
* CRL Distribution URL: http://crl.identrust.com/DSTROOTCAX3CRL.crl (same
as R3)
* Certificate Policies: 2.23.140.1.2.1 and 1.3.6.1.4.1.44947.1.1.1 (same as
R3)

Thank you,
Aaron

[Kurt Roeckx]

On 2021-01-07 01:48, Aaron Gable wrote:
> As mentioned in the blog post, and as we'll elaborate on further in an
> upcoming post, one of the drawbacks of this arrangement is that there
> actually is a class of clients for which chaining to an expired root
> doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
> mode as various clients ran into on May 30th of 2020, when the AddTrust
> External CA root expired.

I'm not sure why you mention OpenSSL prior to 1.1. There was a bug in
1.1.1h that no longer checked for expired roots, but it was fixed in
1.1.1i. OpenSSL has no plan to allow expired roots by default.


Kurt

[Aaron Gable]

In cases where we expect OpenSSL to be validating the chain, we expect that
ISRG Root X1 is also in the trust store (unlike older versions of Android,
where we know that it hasn't been added). As such, there will be two
certificates in the chain which are also in the local trust store: ISRG
Root X1 and the expired DST Root CA X3.

It is my understanding that OpenSSL 1.1.0+, with the `trusted_first` method
as the default chain-building method, will go through the following steps:
1) Receive the chain "EE <-- R3 <-- ISRG Root X1 (cross-signed by DST Root
CA X3)" from the server
2) Look to see if it can complete this chain using certificates from
`-CAfile`, `-CApath`, or `-trusted`
3) See that ISRG Root X1 is already trusted
4) Return this chain, which successfully verifies.

The evidence that this works on OpenSSL 1.1.0+ comes from the very similar
situation this past May. In that case, many servers were serving the chain
"EE <-- Sectigo RSA Domain Validation Secure Server CA <-- USERTrust RSA
Certification Authority <-- AddTrust External CA Root". In that situation,
both the USERTrust RSA Certification Authority and the AddTrust External CA
Root were in various trust stores, and then the AddTrust External CA Root
expired. Clients which were using OpenSSL 1.1.0+ did not begin to fail at
that time, because they were still able to trust the USERTrust RSA
Certification Authority. Clients using OpenSSL 1.0.x were failing, because
they couldn't recognize that one of the intermediates in the chain was in
their own trust store.

If this understanding is incorrect or missing something, we'd love to be
informed.

Thanks again,
Aaron

On Thu, Jan 7, 2021 at 1:10 AM Kurt Roeckx via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

> On 2021-01-07 01:48, Aaron Gable wrote:

> > As mentioned in the blog post, and as we'll elaborate on further in an
> > upcoming post, one of the drawbacks of this arrangement is that there
> > actually is a class of clients for which chaining to an expired root
> > doesn't work: versions of OpenSSL prior to 1.1. This is the same failure
> > mode as various clients ran into on May 30th of 2020, when the AddTrust
> > External CA root expired.
>

> I'm not sure why you mention OpenSSL prior to 1.1. There was a bug in
> 1.1.1h that no longer checked for expired roots, but it was fixed in
> 1.1.1i. OpenSSL has no plan to allow expired roots by default.
>
>
> Kurt

[Man Ho (Certizen)]

I think it is a mistake to assume that the "intermediate" (i.e. your
ISRG Root X1 cross-signed by DST Root CA X3) is the same certificate as
your self-signed ISRG Root X1.  The "intermediate" can only be chained
up to expired DST Root CA X3.

[Kurt Roeckx]

On Thu, Jan 07, 2021 at 09:31:17AM -0800, Aaron Gable wrote:
> In cases where we expect OpenSSL to be validating the chain, we expect that
> ISRG Root X1 is also in the trust store (unlike older versions of Android,
> where we know that it hasn't been added). As such, there will be two
> certificates in the chain which are also in the local trust store: ISRG
> Root X1 and the expired DST Root CA X3.
>
> It is my understanding that OpenSSL 1.1.0+, with the `trusted_first` method
> as the default chain-building method, will go through the following steps:
> 1) Receive the chain "EE <-- R3 <-- ISRG Root X1 (cross-signed by DST Root
> CA X3)" from the server
> 2) Look to see if it can complete this chain using certificates from
> `-CAfile`, `-CApath`, or `-trusted`
> 3) See that ISRG Root X1 is already trusted
> 4) Return this chain, which successfully verifies.
>
> The evidence that this works on OpenSSL 1.1.0+ comes from the very similar
> situation this past May. In that case, many servers were serving the chain
> "EE <-- Sectigo RSA Domain Validation Secure Server CA <-- USERTrust RSA
> Certification Authority <-- AddTrust External CA Root". In that situation,
> both the USERTrust RSA Certification Authority and the AddTrust External CA
> Root were in various trust stores, and then the AddTrust External CA Root
> expired. Clients which were using OpenSSL 1.1.0+ did not begin to fail at
> that time, because they were still able to trust the USERTrust RSA

> Certification Authority. Clients using OpenSSL 1.0.x were failing, because

> they couldn't recognize that one of the intermediates in the chain was in
> their own trust store.
>

> If this understanding is incorrect or missing something, we'd love to be
> informed.

Yes, "trusted first" behaves that way and is on by default since
1.1.0 and can't be disabled. It was not clear to me that the X1
root was in the trust store if you use 1.1.0.


Kurt