Net err cert authority invalid when using letsencrypt on azure

I have looked through previous questions but could not find an answer that works for our use case.

We created a certificate using this tool here: GitHub - fszlin/certes: A client implementation for the Automated Certificate Management Environment (ACME) protocol and uploaded it to our Azure app service.

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.

My domain is:

I ran this command:
openssl.exe s_client -connect -servername

It produced this output:

Certificate chain
0 s:CN = *
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

My web server is (include version):
Azure App service.

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

My hosting provider, if applicable, is:

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

What's the exact order.Download command you're using?

I am using the CLI option:

certes order finalize --out cert-key.pem
certes cert pfx pfx-password --private-key cert-key.pem --out my-cert.pfx

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

There are two trust paths and the PFX seems to only fully cover one of them:

I would try including the other intermediate and see if that helps.

Well, Let's Encrypt sends by default the longer chain 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?

1 Like

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.

1 Like

Thanks for this. How do I go about including the second intermediate?

1 Like

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.

1 Like

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.

1 Like

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:

  • (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.

1 Like

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?

1 Like

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).


So basically, I don't know.


@webprofusion and @Osiris thanks for the help.
I used CertifyWeb to create a new certificate. But somehow, the issue still persists.
checking the certificate here: SSL Checker - Test Certificate and Installation shows that the certificate path is still not trusted.
The server I installed this on is :

I even created another with win-acme and still has the same issue. The server installed on is .

Would really appreciate some more help. Thanks

1 Like

It seems that the certificate checker is to blame (and has become outdated).
SSL Server Test: (Powered by Qualys SSL Labs)


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