
Let’s Encrypt to transition to ISRG root - trygvis
https://scotthelme.co.uk/lets-encrypt-to-transition-to-isrg-root/
======
AnssiH
Interesting that the referenced Let's Encrypt post from 2018
([https://letsencrypt.org/2018/08/06/trusted-by-all-major-
root...](https://letsencrypt.org/2018/08/06/trusted-by-all-major-root-
programs.html)) said

"Some will not, and we’ll need to wait for the vast majority of those to cycle
out of the Web ecosystem. We expect this will take at least five more years,
so we plan to use a cross signature until then."

So half a year ago they expected to continue cross-signing for 5+ years. What
changed?

~~~
Ajedi32
For what it's worth, you'll still be able to use the old roots for another two
and a half years (until September 29, 2021), which is not quite five years
from the date of that old post, but also way longer than half a year.

~~~
AnssiH
I wonder what Google will do with their Cloud Platform Google-managed SSL
certificates that have used Let's Encrypt so far...

But I guess in the worst case I can just buy traditional certificates for a
couple of years.

~~~
blattimwind
You can literally exchange the certificates manually in the chain delivered by
your webserver using a text editor.

~~~
AnssiH
There are no configuration options of any kind in Google App Engine with
managed SSL security enabled (since the point is to let Google manage it),
which I'd rather keep enabled if feasible to avoid having to worry about
renewals etc.

------
michaelt
So what motivates one CA to cross-sign another? I would have thought, if you
were a CA you'd prefer not to enable your competitors - especially one who's
planning to give away the product for free.

~~~
tialaramex
I don't think anybody at Let's Encrypt has spoken on this topic, but in their
case specifically there are both moral and pragmatic reasons to choose to
cross-sign.

Morally is the easy one. If you work for a public CA you presumably think that
the Web PKI is a good idea, and Let's Encrypt helped bring that benefit to
lots more users, so that's a good thing. Consider the question of whether
McDonalds should support a local soup kitchen. McDonalds thinks food helps
bring people together, so why not?

Pragmatically, there are a number of benefits to Let's Encrypt for a
commercial CA. It creates a "brand halo" for the "SSL Certificate" product
class that you benefit from, where positive experiences with Let's Encrypt
result in more customers for you. Growing the market means more opportunities
for you as a seller. I see some misleading analysis of the "SSL Certificate"
market that doesn't include "Does not have a cert" as one of the options. So
they see Let's Encrypt crushing other outfits and assume that's got to hurt
profits. But a site that goes from nothing to a Let's Encrypt cert makes no
difference to sales at the for-profit CA. Even if 100 sites do that, if just
one copies them but chooses to buy a cert, that's an extra sale they would not
make otherwise.

~~~
blattimwind
AIUI IdenTrust was set-up as a sort of self-servicing entity by banks mostly
for banks and their clients, so IdenTrust probably doesn't really care too
much about classic web CA business.

~~~
xnyan
I was going to add this. The choice of IdenTrust was not an accident. It was
and is a very reputable CA but for banking reasons and so is not threatened by
LA's entry into the market.

------
nimbius
ISRG stands for Internet Security Research Group.

~~~
sihoang
This is in their latest blog post "Christine expands our board’s global
perspective with her career experience. She worked for many years in the
Australian government"

I was wondering what impact if she, a board member of ISRG, has to comply with
the Australian encryption laws?

~~~
tssva
Not that I actually would be at all, but hypothetical I would be more
concerned with them hiring an Australian engineer than adding an Australian
board member. What is the board member going to do to compromise operational
security?

~~~
arminiusreturns
Influence hiring to get the engineer spy in. Also CIA docs have been published
that said they had a system where people would purposefully tie down a company
by being inefficient and causing beaucratic messes[https://www.cia.gov/news-
information/featured-story-archive/...](https://www.cia.gov/news-
information/featured-story-archive/2012-featured-story-
archive/CleanedUOSSSimpleSabotage_sm.pdf)

------
viraptor
They haven't really published a list of good/bad clients. I'm interested in
what's the practical cutoff point with mobile phones? I expect desktop
browsers will be less of an issue.

~~~
regecks
On Android, the root was first added in Nougat (~half of devices according to
Android Distribution Dashboard). But I think that browsers (like Firefox and
Chrome) on Android tend to bring their own cacerts rather than using the
device's, so it's probably not as bad as it looks.

To that end, it was added to NSS 3.26/Firefox 50 (November 2016) and to Chrome
57 (March 2017).

On iOS, it was first added in iOS 10 (2016).

The root itself was created in June 2015.

Edit: they also have a list on their website -
[https://letsencrypt.org/docs/certificate-
compatibility/#know...](https://letsencrypt.org/docs/certificate-
compatibility/#known-incompatible) . It lists Android < 2.3.6 as being
incompatible .. I wonder if that's updated for the non-cross-signed
intermediates.

~~~
emj
I was eating breakfast with a multitude of Android phones around me and four
"older ones" could not access that site. The oldest that could connect was ~5
months old, all using new Mobile Chrome versions.

~~~
londons_explore
The reality is, for a bunch of usecases, you're gonna need to support 15 plus
year old devices.

So Windows XP...

There are a lot of old systems out there running API's, automation, industrial
systems, etc. They never get updates, and are expected to last decades. Most
of them aren't on the public internet, but HTTPS would still be a good idea.
This change is going to mean a bunch of them just get changed over to having
no encryption.

~~~
pcnix
This is because the IdenTrust root is expiring though, it's not something
LetsEncrypt can do anything about.

~~~
panarky
_> it's not something LetsEncrypt can do anything about_

This is going to cause a lot of stuff to break, and it's 100% LE's
responsibility.

HN's root cert is valid through 2038.

LE could have gotten cross-signed by a cert that didn't expire so soon, but
they didn't.

~~~
londons_explore
> LE could have gotten cross-signed by a cert that didn't expire so soon, but
> they didn't.

And they still could.

------
rocqua
I'm not an expert of certificates, but some quick skimming of
[https://tools.ietf.org/html/rfc5280#section-4.1](https://tools.ietf.org/html/rfc5280#section-4.1)
suggests that a certificate only references the issuer certificate by name.

Since, according to the article, the two different Lets encrypt intermediates
have the same key, and the same name, they are interchangeable? As in, could I
just replace the intermediate in my cert-chain and have everything continue
smoothly?

The end of the article suggests that this can't happen, but I can't quickly
find what would stop this from happening.

~~~
theandrewbailey
Yes, they are interchangeable.

On my blog ( [https://theandrewbailey.com/](https://theandrewbailey.com/) ), I
have a "health check" page that includes all available trust chains. For my
Let's Encrypt certificate, it shows 2: one through an intermediate to the DST
Root, and another intermediate to the ISRG Root. I can verify that both exist
and are used (though one certificate and intermediate are loaded and served):
the current Firefox release (and all other browsers I've tried) uses the DST
root, but Firefox Developer Edition uses the ISRG root.

It seems to make sense: certificates don't sign certificates, keys sign
certificates (more specifically, certificate requests). I don't see an obvious
reason that a single certificate request can't be signed more than once. If
one is, trust should flow through either certificate, since the certificate
says that the signer verified that the holder has the associated private key,
and if that private key signed another certificate, it should not matter which
intermediate the trust goes through, so long as the root on the other end is
trusted.

~~~
rocqua
Thanks! I can't seem to find the direct 'health-check' page though.

Also, according to the spec, certificates sign a 'tbsCertificate' which
contains all data of a certificate except for the actual signature and the
field that determines what signing algorithm was used.

~~~
theandrewbailey
It's behind a login, but you can see the browser certificate chain in the
browser UI itself. That should work for any Let's Encrypt certificate.

------
founderling
Is it still hard to do wildcard certs with them? That is one of the reasons I
don't use let's encrypt.

~~~
LeonM
Is there still a valid use-case for wildcard certificates when using Lets
Encrypt? AFAIK wildcards were used for financial reasons and laziness (since
the traditional method of acquiring a cert was cumbersome), but with LE none
of those arguments make sense.

Why not just fetch a different cert for every subdomain you use? It's also
better security practice as this allows you to use different key per subdomain
and the possibility to revoke bad or unused certs.

~~~
deadbunny
LE rate limits[1] can be a hassle in large environments. Their solution is SAN
certs which are IMHO only mildly better than wildcards.

1\. [https://letsencrypt.org/docs/rate-
limits/](https://letsencrypt.org/docs/rate-limits/)

~~~
LeonM
I did not know about that, thanks for sharing that information!

------
ilaksh
How exactly would I set up my files or nginx config to use the old root?

~~~
tialaramex
You don't need to "use" the old root, you want to configure the chain of
certificates provided so that it links back from your leaf cert to Identrust's
"DST Root CA X3" not "ISRG Root X1". Specifically the chain will be just one
cert, an "intermediate" which you want to ensure is the one cross-signed not
the new one.

This provides a hint to the client that it should trust this certificate
because it can follow the trust back down the chain to DST Root CA X3 (which
it trusts) not to ISRG Root X1 which is too new-fangled for it to have heard
of.

This page has both flavours of intermediate:

[https://letsencrypt.org/certificates/](https://letsencrypt.org/certificates/)

You want the one labelled: Let’s Encrypt Authority X3 (IdenTrust cross-signed)

In nginx you need to concatenate the leaf certificate from Let's Encrypt
(often a file named "cert.pem") with the file you downloaded from that site,
to produce a chain, which you could call mychain.pem, and then tell nginx
that's your certificate chain with a config line like:

ssl_certificate /some/path/to/mychain.pem

where right now you may see

ssl_certificate /where/letsencrypt/puts/fullchain.pem

