Certificate chain stopped working on older android devices

My domain is: *.api.agromanager.eu

I ran this command: certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.api.agromanager.eu -d *.api.greeneryconnect.eu -d *.api.agromanager.net

It produced this output: all okay

My web server is (include version): Azure webapp

The operating system my web server runs on is (include version): Windows server

My hosting provider, if applicable, is: Azure

I can login to a root shell on my machine (yes or no, or I don't know): I don't know for sure

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no - manual uploading

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): latest

I renewed my certificates last week and there was no issue till monday. (or maybe saturday but then most of our customers aren't working).
On monday all android scanners with version 5.1.1 stopped working.
When checking the certificate chain on the device:
*.api.agromanager.eu -> R3 -> ISRG Root X1
For the scanners I could work around it by sending the customers a stagenow code to install "ISRG Root X1" certificate on the devices.
(but now I am getting customers with android 6.0 on their phone and I can't request them to install a root certificate)

The weird thing is that if I check the chain in chrome, I get:
*.api.agromanager.eu -> R3 -> DST Root CA X3
I googled and I found out that ISRG is replacing CA X3 but that this should not be a problem for android till september 2024 (or something along those lines)

Can you help me understand why the scanners are showing another chain?
Because I think if they used the DST Root CA X3 that it would still work.


1 Like

Hi @boeykes, and welcome to the LE community forum :slight_smile:

There are currently two active chains.
Recently LE switched to include the longer expiry path.
But browsers, scanners, and such are free to build the chain as they see fit.
Some may choose the path based on alpha order, some may choose the path based on the lunar cycle.
That is not something anyone can control externally.
If you want to check which chain your servers are currently serving, here's a free online tool for that:
SSL Checker - Test Certificate and Installation (certlogik.com)

There has been a lot of discussion about older Android systems on this forum recently.
Your concerns may have already been answered in one of those topics.

Hi @rg305

Thank you for the quick response.
If I understand it correctly, it is up to device to determine which chain it uses.
I tried the SSL Checker and I got:

Do you know if this is a setting that I am missing in gerenating the pfx?
The commands that I use are:

#To generate the certificate on a local ubuntu VM
certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns -d *.api.agromanager.eu -d *.api.greeneryconnect.eu -d *.api.agromanager.net

#To convert it to pfx for Azure
openssl pkcs12 -inkey /etc/letsencrypt/live/api.agromanager.eu/privkey.pem -in /etc/letsencrypt/live/api.agromanager.eu/cert.pem -export -out /home/brent/agromanager-api-customers.pfx

Do you know if I can fix my issue somehow in the pfx?


1 Like

I think it would be too late by then.

cert.pem does not provide any chain information.
Try using the fullchain.pem file instead; which includes the cert and one of the intermediate chains.


I tried the fullchain but it didn't help.
Despite the fact that I love Let's Encrypt, I bought an SSL certificate from Comodo for our API.
This way the clients can connect again.
For all the other applications I will still use Let's Encrypt :grinning_face_with_smiling_eyes:

Thank you for the support

1 Like

Exactly how was that cert implemented any differently?
OR is it just the chain they provided that fixed your problem?

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