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.
Hi @boeykes, and welcome to the LE community forum
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.
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?
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
