May I ask how this data has been acquired? Making a HTTPS to the hostnames in a certificate after issuance?
4 Likes
Yes, you nailed it! Within the first 48 hours of issuance we attempt a single TLS handshake and inspect the chain for intermediate mismatches. If your server doesn't respond on the first attempt we do not retry. While we fully expected that some clients may hard-code the intermediate, we were super jazzed to see that the overwhelming majority of Let's Encrypt subscribers are using clients that do not.
3 Likes
We will be serving the Android-compatible chain.
3 Likes
Thanks for clarifying things for us, beautifulentropy. I might write-up some kind of calendar/collection guidance in one place at some point in the near future as there are a lot of correlated information tidbits spread here and there.
2 Likes
After some discussions with my peers we have decided that the API will serve the shorter chain.
3 Likes
That's quite a change, right? Probably warrents a change in OpenSSL Client Compatibility Changes for Let’s Encrypt Certificates and also invalidates the whole huge blog post Extending Android Device Compatibility for Let's Encrypt Certificates - Let's Encrypt - Free SSL/TLS Certificates ? Or I'm interpreting the question incorrectly: @WillyYang might indeed literally talk about the chain used by the API endpoint itself. I interpreted it as "which chain will be send by default when issuing a certificate".
3 Likes
I am referencing the chain used by the API endpoint itself. Apologies for any confusion there!
4 Likes
Just so I'm understanding fully, we're talking about:
- the API endpoint serving the shorter chain (rooted at self-signed ISRG Root X1) to ACME clients for purposes of securing the ACME transactions
- the production primary chain becoming the longer chain (rooted at ISRG Root X1 signed by DST Root CA X3)
- the production alternate chain remaining the shorter chain (rooted at self-signed ISRG Root X1)
Thus the only change to the upcoming production primary chain is this:
leaf <- R3 <- DST Root CA X3
becomes this:
leaf <- R3 <- ISRG Root X1 <- DST Root CA X3
3 Likes
Yes, that summary is correct, modulo the language "rooted at".
The ACME API will offer two chains for clients to select between when downloading their newly-issued certificate:
- leaf <- R3 <- ISRG Root X1 <- DST Root CA X3 (self-signed)
- leaf <- R3 <- ISRG Root X1 (self-signed)
The first of those will be the default, which clients will get unless they have been configured to request an alternate chain.
The second of those will be the one used by the ACME API to conduct TLS handshakes when clients first connect to it, since we do not have clients which run on Android and so do not need the extra compatibility provided by the default chain.
6 Likes
That's surprising to me.
2 Likes
I'm not really into mobile development, but I'd guess TLS servers on mobile OSes aren't terribly common unless except maybe for people running Android on IoT devices.
4 Likes
I used to run one for mobile development, but Google really hosed it when they tweaked some "security concerns" regarding what certain apps were doing.
5 Likes
Even if the server isn't on Android, a mobile ACME client using DNS-01 to get a certificate and upload it to a server sure isn't the craziest idea I've ever heard.
And yeah, an IOT-type device might want to get a cert, and running Android on one of those wouldn't be the craziest idea either.
But hopefully in either case it's be easy enough to ensure that ISRG Root X1 was in the trust store.
3 Likes
If you really want to use an ACME client on Android, or anything that handles private key material, you should make sure you have a version of Android that still receives security fixes and updates (and make sure to install them!) - and these should not require the compatibilty chain anyway.
5 Likes
3 Likes
Hello,
While Android will continue to honor DST Root CA X3 even after expiry, does anyone have details about iOS compatibility for either of root certs - ISRG Root Certificate or DST Root CA X3?
Thanks
3 Likes
All modern versions (at least iOS 10 and newer) of iOS trust ISRG Root X1. You should anticipate that the vast majority of iPhone/ iPad users run a new enough version of the OS to trust ISRG Root X1 because Apple's tight control over iOS ensures most of its customers can upgrade for several years after purchasing a product, whereas some Android products are shipped running an already obsolete version and are never updated.
3 Likes
FYI, I somewhat recently updated Certificate Compatibility - Let's Encrypt - Free SSL/TLS Certificates. It now lists the major root stores that trust ISRG Root X1, along with the first version that included it. @tialaramex is correct that iOS 10 trusts ISRG Root X1. I've confirmed iOS 9 does not, and included a link on that page. Any corrections are welcome!
4 Likes
I believe you can add current PS 4 firmware to the list which trusts ISRG Root X1 based on this document. If it's important to check the reality matches the claims, I can have a friend with a PS4 visit any test site you prefer as a favour, let me know.
3 Likes
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