[Solved] Certificate stops working recently, NET::ERR_CERT_AUTHORITY_INVALID error even after renewal

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. https://crt.sh/?q=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:

I ran this command:

It produced this output:

My web server is (include version):

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

My hosting provider, if applicable, is:

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

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

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

certbot 0.31.0

it has been working fine in the past 4 years, earlier this year (I don’t know the exact time), the certificate is receiving NET::ERR_CERT_AUTHORITY_INVALID in Chrome again. I tried --force-renewal, but the new certificate still have the same error. Please help, thanks

1 Like

Hi @fangq

there is a working certificate. Checked with Chrome / FireFox, all ok. Checked that port via https://check-your-website.server-daten.de/?q=kwafoo.coe.neu.edu%3A7788 - the same.

A valid certificate:

expires in 90 days	kwafoo.coe.neu.edu - 1 entry

created today.

If you see the error again: Perhaps share a screenshot.

1 Like

Your site isn’t sending the intermediate certificate, which is required for many browsers to verify the entire chain. You should use fullchain.pem in stead of cert.pem in your Apache configuration.


@Osiris, thanks a lot, replacing cert.pem by fullchain.pem solved the problem.

is this a new requirement? I have been using the cert.pem for years and did not have such issue.
any how, glad that this is resolved!

a related question - when I played with certbot renew today to workaround this, I found certbot created a domain.name-001 folder, aside from the domain.name folder in /etc/letsencrypt/live/. I am wondering how certbot renew these certificates? will both be renewed? can I remove the -001 folder and only reference the original one?

thanks again


No, it's not new. But some clients are smart enough to use the "CA Issuers" field from the "Authority Information Access" part of the certificate to get the intermediate certificate themselves, so perhaps you didn't notice it before yourself. But not every client does that. Therefore it's very wise to provide the client with the intermediate next to the certificate itself by using fullchain.pem. Unless you want to run into problems like you had now :wink:

Perhaps users of your site did have this issue, but never went through the trouble of telling you. Probably they just assumed your site was broken.

You can check your current certificates with certbot certificates. Also, you can test renewing with certbot renew --dry-run and see which certificates will be renewed.

Depends which certificate folder is being used by your webserver. If you delete the folder while your Apache or nginx requires a certificate from it, they will fail to start. If you're pretty sure you really don't need the -001 folder, you should delete the certificate with certbot delete --certname ${cert-name} where ${cert-name} is the name of the certificate which can be found with certbot certificates. (Which should also be the name of the folder, but you can never be too sure.)

Also, please play around using the --staging option if you don't actually require a working certificate. Using the staging server will get you a "fake" certificate, but wouldn't require the amount of resources it costs for Let's Encrypt to sign an actual working certificate.


What client do you use?

I've never seen that a browser blocks a certificate if the intermediate certificate is missing.

1 Like

Re @JuergenAuer, the client is Chrome 80.0.3987.106 (Linux version).

A month ago, another server of mine had similar error due to the missing intermediate certificate, and our computer helpdesk solved it.

Re @Osiris:

Perhaps users of your site did have this issue, but never went through the trouble of telling you. Probably they just assumed your site was broken.

this is totally possible. This is an internal site that is only used by my group. The difference is that previous Chrome gave people an option to continue despite the warning, now that option is gone, there is no way to get around NET::ERR_CERT_AUTHORITY_INVALID

You can check your current certificates with certbot certificates . Also, you can test renewing with certbot renew --dry-run and see which certificates will be renewed.

certbot certificates and certbot delete --cert-name worked beautifully! I removed the unwanted certificate, restarted apache and the site is working fine.

much appreciated for both of your inputs! now I feel more comfortable to manage these certificates moving forward.

1 Like

It's actually quite common and used to be a regular and recurrent topic on this community. Some clients however cache the intermediate if it was send in an other TLS connection. In that case missing that intermediate somewhere isn't an issue. And since Let's Encrypt currently is like, everywhere, caching its intermediate would be quite common.


Thanks. Interesting, the Windows-Chrome doesn't show that problem.

I know. But mostly, it's not a blocking problem. It's - sample - a blocking problem if someone has an Ookla Speedtest (port 8080). So the user has no problem with his browser, but the Ookla check says: "Invalid".

And Ssllabs doesn't allow to test non-standard ports.

PS: @fangq : Check


with your browser. That shouldn't work. With Windows-Chrome - no problem.

1 Like

check https://incomplete-chain.badssl.com/ 1
with your browser. That shouldn’t work. With Windows-Chrome - no problem.

I see an orange page with the below warning - as you have expected


The certificate chain sent by this site is missing an intermediate certificate. This will cause a certificate error unless the browser already has the intermediate certificate in a cache or implements AIA fetching.

1 Like


the normal content of that page. These https://badssl.com/ - pages have that look.

So you don't see a browser warning, but the intermediate certificate isn't send.

1 Like

Since you mention Chrome, I believe Chrome does AIA Chasing. “AIA Chasing” means when it isn’t given a sufficient chain of certificates, it will look at the Authority Information Access (AIA) fields in the certificate it was shown, and use that to try to fetch another certificate until it has a complete chain.

AIA Chasing will fail if your systems have restrictive network access such that Chrome can’t reach the URLs from the AIA fields.

A reason why you may see fatal errors with no option to “continue despite the warning” may be HTTP Strict Transport Security (HSTS). The HSTS headers promise that a site is delivered securely, and so insecure access should be prevented. If you’ve just started using HSTS that would explain changed behaviour. Since the site promised previously that it has working security, the option to continue anyway is disabled as it must be unsafe to do so and this could be an attack.

In studies users will always try to continue anyway, so it turns out the only way to protect them is to refuse to let them.


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