Renewal Cert (PoshACME) getting reports of Invalid CA

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: !.filestoreonline.com (demos.filestoreonline.com)

I ran this command: submit-renewal *.fielstoreonline.com

It produced this output:

My web server is (include version): Azure Application Gateway WAF V2

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

My hosting provider, if applicable, is:

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

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Azure Web Control Penal

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

I recently renewed a wildcard cert, which is used on an Azure AGW for roughly 50 listeners on the front-end. When the cert was initially created, I used the AlwaysNewKey switch, so a new private key was also generated. The issue, however, is when I applied the new cert to the AGW, we began receiving reports of NET::ERR_CERT_AUTHORITY_INVALID from clients connecting to their respective endpoints. For what it's worth, I do not get error when connecting to the same endpoints on my own system.

When investigating, the root and intermediate certs did not change that I can tell. I did revert the cert to the old cert and it appears that these customers are not seeing the issue now.

Cert copies have been uploaded for review and hopeful insight from the community!
cert_new.pem (1.8 KB)
cert_old.pem (1.8 KB)

That spelling is different than this spelling

Which is correct?

1 Like

Using CSR Decoder and Certificate Decoder with your cert_new.pem I see:

1 Like

Typo on my end! Should be *.filestoreonline.com

Using SSL Server Test (Powered by Qualys SSL Labs) with demos.filestoreonline.com here SSL Server Test: demos.filestoreonline.com (Powered by Qualys SSL Labs) I see:
Chain issues Incomplete

So, based on this, would you say that the clients' browsers are not building the chain from the supplied cert and that the fullchain cert should be what's placed in the AGW?

Here are 2 links on chains

Also expand shows that R3 is not in the chain being served and cause clients an Extra download

2 Likes

You're not sending any chain at all, just the end leaf certificate.

I'm not familiar with AGW, but perhaps you did send a chain with your previous cert installed?

5 Likes

As others have mentioned, the problem does seem to revolve around the fact that AGW is only serving the leaf certificate rather than the leaf and intermediate(s). When you upload the PFX to Application Gateway, are you using the cert.pfx or fullchain.pfx file?

This StackOverflow question and associated blog post suggests the V2 Gateways need the full chain in the PFX:

5 Likes

That would probably explain it then! I had uploaded the cert.pfx, not the fullchain.pfx file. We will reupload using fullchain.pfx and hopefully that will be the resolution needed.

2 Likes

For anyone interested, this the result from SSLLabs after uploading the fullchain cert: https://www.ssllabs.com/ssltest/analyze.html?d=demos.filestoreonline.com

This will be noted for later instances of manual renewals in Azure Gateways.

2 Likes

However @Bob.Gunn the old cert is still being served

2 Likes

By design at the moment, thank you! Waiting on the business owner to approve the change to the new cert again.

2 Likes

Excellent! :slightly_smiling_face:

2 Likes

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