Older Android devices

Issuance Policy
1

Hi,

A client manufactures Android devices and they also have a lot that are older than Android 8.
So I was closely following the LE blog posts about the changes, now today the topic came back during a meeting and I was double checking to make sure what the impact would be for us.

I was reading this blog post: https://letsencrypt.org/2020/12/21/extending-android-compatibility.html
But this part was confusing me:

What happens when the new cross-sign expires? This new cross-sign will expire in early 2024. Prior to that, perhaps as early as June 2021, we will be making a similar change to what we intended to make this January. When we make that change, subscribers will have the option to continue using DST Root CA X3 by configuring their ACME client to specifically request it.

"subscribers will have the option to continue using DST Root CA X3 by configuring their ACME client to specifically request it" but from my understanding this shouldn't be the case and it will use DST Root CA X3 by default or not?

We just want to make sure because the impact might be very big very us if this is not the case.

So I think my main question is will certbot by default continue issuing certs that use DST Root CA X3?
And for how long? In the blog post it is mentioned until early 2024.

2 Likes
2

I think that paragraph in the blog post is just wrong now, based on outdated information from the original plan. I'd suggest looking at the recently-put-together announcement on upcoming chain changes:

But there's certainly been a lot of confusion by a lot of people about what's happening.

5 Likes
3

if your client can push update to their device, do a porper job and push a update with newer root CA list with ISRG X1 cert included. (and other security patches if possible)

2 Likes
4

@jple: I'm assuming you're the one to contact about this, or at least you'd know who to bring in. I think the above-quoted paragraph in the blog post is wrong now that the plan is to have DST Root X3 as the root of the default chain. If so, can you see if the blog post can get updated? I suspect that information about the old plan still being out there may be behind a lot of the confusion people are having.

3 Likes
5

Thanks Peter! I'll get it done first thing tomorrow!

3 Likes
6

i've got an older android 7.0 device and the cert for https://waverley.smartcitiestransport.com/ renewed two days ago. i just noticed today that it's not working in chromium (web view) but it works fine in chrome. logcat is giving me an error like E chromium: [ERROR:ssl_client_socket_impl.cc(947)] handshake failed; returned -1, SSL error code 1, net_error -202 so i assume something has changed in the cert. i don't really know how to look at the certificate, but do i need to do something to get a compatible certificate?

2 Likes
7

did some more testing:

  • not working:
    • android 6.0 chromium/web view
    • android 6.0 chrome
    • android 7.0 chromium/web view
    • latest chrome on win7-32
  • working:
    • android 7.0 chrome
    • android 10 chromium/web view
1 Like
8

@jayenashar which ACME client do you use for certificate renewal, is it certbot?

[Edit: I believe you have the ISRG X1 Root chain as your primary chain but interestingly there are two certifications paths shown here: SSL Server Test: waverley.smartcitiestransport.com (Powered by Qualys SSL Labs)]

1 Like
9

Here is which chain the website is using:

$ openssl s_client -connect waverley.smartcitiestransport.com:443 -servername waverley.smartcitiestransport.com
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = waverley.smartcitiestransport.com
verify return:1
---
Certificate chain
 0 s:CN = waverley.smartcitiestransport.com
   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
---

It looks like it isn't the recent default chain.

1 Like
10

The first chain shown by Qualys SSL Labs is which is sent on the connection. The second chain is constructed from the CA Issuers - URI:http://r3.i.lencr.org/ URL in the leaf certificate. That is a different R3 intermediate certificate than sent on the TLS channel, it is signed by DST Root CA X3 instead of ISRG Root X1

2 Likes
11

Thanks, yes so in most [acme] clients you'd have to specifically ask for the ISRG Root X1 chain I think?

2 Likes
12

The web site waverley.smartcitiestransport.com is using the recent non-default chain, or the older chain (I do not know, are they the same?). Many ACME clients permit the selection of the non-default chain, and yes, someone have to specifically ask for that. So your previous question is pertinent, what ACME client the user is using? Is there any special flag provided to that client? Another option is that the chain is not updated from the ACME client towards the webserver, that would be bad.

1 Like
13

I will ask my hosting provider, which is getting the certificate for me. And I will point them at this thread which seems to have all the useful information. Thanks.

2 Likes
14
ignore this

This is a 20+ character message to satisfy the silly requirement.

1 Like
15

Thanks griffin. That means, that the alternate certificate chain is used and provided by the webserver.

1 Like
16

Maybe for both past and present? :thinking:

Update: I got to thinking about this more... if the provider is actually sending ISRG Root X1, it would almost certainly be the ISRG Root X1 signed by DST Root CA X3 as it would make no sense to send the self-signed root (and thus be sending the entire chain). If ISRG Root X1 is absent from the chain that is being sent then the self-signed is assumed to be trusted.

So this:

seems to imply the alternate chain (with trusted, self-signed ISRG Root X1). I may have way overexplained all this. :sweat_smile:

1 Like
17

@jple Just giving you a little nudge. :slight_smile:

1 Like
18

Updated to include a warning that the information may be incorrect and to check this page on the forum: Production Chain Changes

PRs:

As always, feel free to make a PR in our GitHub repo with these changes and ping me @jaykaypea so I can have someone from our team merge! I love having an open source website. :smile_cat:

1 Like
19

@jple

Can you please commit the PR that I submitted days ago of similar nature? :slightly_smiling_face:

1 Like
20

YES, you are awesome @griffin, thanks for the ping!! :smiley_cat:

1 Like