Older Android devices

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

@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

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

3 Likes

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

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

@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

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

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

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

2 Likes

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

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
ignore this

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

1 Like

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

1 Like

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

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

1 Like

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

@jple

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

1 Like

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

1 Like

Thanks. :blush:

It was actually requested by a new member. I thought it was important and PRed it immediately.

1 Like

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