I ran this command: A friend works in a gov department with two networks, one more secure and one less secure and more open. The domain works fine on the more secure network, but returns an ERR_CERT_AUTHORITY_INVALID error on the open network. Both Chrome and Edge return the error. Yes, I double-checked this, you would think it would be the reverse, but it is only on the "less secure" network on which there is an issue.
It produced this output: I understand that the issue is likely my friend's network. But it is really important that my site be accessible there, so it is my problem now. I am hoping that someone has run into this, and can help me with suggestions to help my friend figure out why machines on their less secure network would have issues.
My web server is (include version): Hosted by SiteGround.
The operating system my web server runs on is (include version): Believe it is Fedora Linux.
My hosting provider, if applicable, is: Siteground.
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): I can ssh to the server, but do not have root access.
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): Unknown.
From my point of view there's nothing wrong with the certificate.
Without a more detailed error from this friend of yours I don't think there's much we can do to debug this remotely from the public internet. That friend should make screenshots of the certificate that the browser(s) have received. (My guess is some MitM firewall or other "security" device.)
As @Bruce5051 pointed out, their info is not credible.
I just wanted to add that "your" SSL test site gives the same error even for this forum's domain name. It uses a poor cert validation technique that might have worked some years ago for Let's Encrypt but has not been kept updated.
Use any of the sites Bruce offered rather than that one
Is there useful language I can use to help him talk to his IT people? Like, as an unrealistic example to illustrate what I mean, "it looks like your firewall is taking over communications on port 443 and misdirecting them to your internal certification authority. This is usually because switch TRAPCA is set to 001 when it should be set to 002".
Or other useful questions / information / communication I can give my friend to help solve this on his side?
Is your friend working at the Nuclear Regulatory Commission by any chance?
I don't get any other reference to "NRC" that makes much sense.
Often, companies will set up their own private certificate authority and distribute that private root certificate among all the company computers, so their firewall can silently intercept all the trafic and do deep packet inspection even within an HTTPS connection. However, if one would plug in their own device, they wouldn't have this private root cert installed and thus get an error.
Also, this problem should also occur for other websites, not just yours.
Yes, my friend works at the "National Research Council", NRC. Which helps explain why, in his network, it says the CN, O, and U are NRC.
However, what makes it Let's Encrypt relevant is why my site is the only one that has this problem. On a daily basis, many people on his network visit sites all over the world, and as far as my friend knows, my site is the only one to have this problem, using Let's Encrypt .
Could there be something around (and I'm using very imprecise language here because I am guessing far beyond my expertise) that R11 is not a root certificate authority but farther down the chain, whereas most other sites have certificates that are authenticated by a first level root CA? Or something different about R11 and Let's Encrypt compared to other certificate setups?
I will pass on this information to him to see if there is something their IT can do. But since my site is the only one with the problem, I can see how their IT people would ask why it is their problem, and ask what is different about Let's Encrypt, or the way it is set up on my site.
We use Palo Alto firewall in the organization I am working. This firewall has also deep inspection enabled, terminating the TLS connections. However, we maintain a list of well-known websites, there we do not terminate the connection, just let them passthrough. May be your friend is accessing mostly similarly sites that are whitelisted from deep inspection?
I'm pretty sure that this is most certainly not a Let's Encrypt issue. Chances are that among those working sites your friend can visit, one or more are also secured by a Let's Encrypt certificate, as Let's Encrypt has a market share of about 60 % worldwide.
R11 indeed is not a root certificate, but an intermediate certificate. However, your site also sends this intermediate in the TLS ClientHello, which it should do. That way, browsers can use their internal root store to generate a chain from the certificate from your site, using the intermediate, to the root certificate in the browsers root store.
This is normal CA behaviour and not different from any CA. In fact, publicly trusted CAs are not even allowed to directly sign an end leaf certificate using the actual root certificate. An intermediate is mandatory.
That said, who knows what kind of settings the tech boys and girls of National Research Council have configured in their firewall?
In the link about market share above there's also a section called "Popular sites using Let’s Encrypt". Your friend could try those sites and see if it's Let's Encrypt or not. If all of those sites also refuse to work, then maybe Let's Encrypt indeed is the issue.
Thanks very much folks. My friend did some testing, and most Let's Encrypt sites were accessible, but some were not, strong indication of a whitelist at play. He will check further, and I will advise the outcome.
Confirmed, it was simply a whitelist problem. As @bruncsak noted, there must be a firewall that is terminating TLS connections unless whitelisted. The last post by @Osiris was helpful to my friend (he came onto this forum and read the thread).
A request was made to whitelist, and now the site is accessible. Thanks to all for the help.
