The certificate was exported as .pfx and the full chain was included in the .pfx file.
We have been using Let's Encrypt for a while with no issues.
Some of our clients suddenly start reporting "net err cert authority invalid" error on their browser and our mobile app was throwing up a similar error.
Well, Let's Encrypt sends by default the longerchain since begin May.. So it's kinda odd why certes would only use that short chain chaining up to the ISRG root?
Although I'm seeing you're using an ECDSA certificate.. I thought those followed the usual RSA rules, but I might be mistaken.
Anyway, I'm not familiair with certes, but you don't have the --preferred-chain option set to "ISRG X1 Root" somewhere, don't you? Perhaps a configuration file, if that's even possible?
Thanks for this. The CLI option does not specify setting the --preferred-chain and in any case, I don't know what the options for --preferred-chain are.
I would rebuild the PFX manually with both chains - just to test if that is the solution.
If so, then you would need to look for an automated way.
If not, then back to square one...
The version of Certes you can download doesn't understand preferred chain, so it's going to use the first thing it sees, unless you are using a new build that you've compiled yourself.
I'm guessing the clients who see an error are using old version of Android.
Thanks for the clarification @webprofusion
I want to ask if this affects the Nuget versions too.
ALso if I compile and use a new build, what options should I use for --preferred-chain to prevent the issue.
The clients also reported the issue on Chrome, so I can't be sure it's an android-only problem.
Thanks
Was it Chrome desktop? If so that shouldn't have any errors.
Hmm, if you fetched the certes cli using Nuget you might get NuGet Gallery | Certes 2.4.0-beta0001 which is a very recent update and internally it does know about preferred-chain options but as far as I know the cli doesn't have an option for it yet.
Certes has an unusual maintenance history as it was briefly orphaned but now may be maintained again(?).
I'd suggest using a different tool to get your PFX, any of these will work normally and follow the default DST Root CA X3 chain:
https://certifytheweb.com (my app, it's uses a modified version of the certes library with additional fixes)
win-acme
Posh-ACME
[Edit: or just use certbot then convert the resulting certificate to PFX. You also have the option with any of these to simply use a different ACME CA, such as BuyPass Go or Zero SSL, that way you can avoid the Android issue].
Thanks @webprofusion
You replies have really been helpful. I will try some of the options you listed especially your app!
The app looks quite good and should work easily for our use case.
Best regards.
I don't understand. The chain served now is end leaf cert <- R3 <- ISRG X1. Let's Encrypt has never offered that chain as the primary chain as of yet. So howcome would Certes use a non-default chain?
I think this is a recent beta version that may not be widely used and may have a bug, I haven't tried it myself - certes has a CLI and a library, Certify uses a version of the library (currently my own fork).
