Users of old devices unable to use my website due to Sept. LE expiration

My domain is: https://bookclubz.com
API domain is https://api2.bookclubz.com

Many users of my site use outdated computers that don't trust the new LE certificates. They seem to be getting "this site is insecure" warnings across the web for LE SSL certificates, and in general they're just bypassing these by clicking "trust this site".

They're doing this for my site, https://bookclubz.com, which is fine. The issue is that our client makes API calls to https://api2.bookclubz.com, and these calls are being blocked with an ERR_CERT_DATE_INVALID error. Because they can't make calls from their client to my API, the site becomes unusable.

If the user visits https://api2.bookclubz.com in their browser, and clicks "trust this site", the errors go away.

My question is, is there a way for me to make my site compatible with these older clients? I've seen that users can download the ISRG Root X1 certificate, but most users don't know to do this. I suppose I could serve my API from a domain like Oh no! Looks like you lost your bookmark., but I was hoping there's an easier workaround to keep my site compatible with older clients?

Thanks for maintaining LetsEncrypt, and for any help the community can provide!

1 Like

Can you provide more details about your client and a url for the api call (if possible).

Your server sends the default "long chain" for better support of older android clients (both your apex and api2). What os and browser versions are your clients using that get the "site insecure" message? Or, is that related to your api calls failing?

3 Likes
echo | openssl s_client -connect api2.bookclubz.com:443 | head
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 = api2.bookclubz.com
verify return:1
CONNECTED(00000005)
DONE
---
Certificate chain
 0 s:CN = api2.bookclubz.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
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

You could try using the shorter/alternate chain.
OR
Try switching to a completely different trust chain via another ACME friendly CA.

3 Likes

@MikeMcQ The client is a user of my website who's running an older Macbook from around 2012. I can get the exact details if that's helpful, but the main issue is that they haven't run this workaround yet for their client: Let's Encrypt DST Root CA X3 expiry Sept 30th 2021 | Certify The Web Docs

The URL they was trying to click is one like this one: You've been invited to join a club on Bookclubz

If you visit this URL, note that it also makes a GET request to the API server at https://api2.bookclubz.com/clubs/5958066/join/7a0d14/ after the component gets loaded. The user clicks "trust this site" for the GET request to the main server, but this second GET request fails. This is just one example; there are many GET/POST requests directly from the client to the API server when the user is navigating the site. As I type this I wonder whether making the request a POST instead of a GET to the API server would make any difference...

Thank you again for your help!

1 Like

OK. I understand the client is just the browser and you have different domains in some of the URLs in the page. If the failure is due to the certificate a POST will not behave any different.

In your first post you said "Many users of my site use outdated computers". So far you have only described an older Macbook with a possible resolution that has not yet been tried.

If you have a wide variety of older clients you may need to switch to a different certificate authority. Lets Encrypt has the default "long chain" to allow use with older android clients but at the expense of certain other older clients. LE also offers a "short chain" which works for some but then not for older android. See this thread.

If you just have a handful of cases we could maybe direct you to options for them. Those clients may welcome such assistance as they are likely running into a variety of security related problems. For example, we just worked through a case with a very old android whose default browser failed but chrome worked. Sometimes it is easy (once you know!).

3 Likes

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