LE certs result in err_cert_authority_invalid from DoD network?

First, I have to say that I am not on a DoD network, and cannot reproduce this myself. I also have a limited ability to ask for more information from the person that reported it to me. I’m sorry, but that’s just how it is.

I received a report that IE and Chrome returned err_cert_authority_invalid when viewing https://www.hdfgroup.org (my site). I’ve also learned that the same thing happens going to https://eff.org, https://www.howsmyssl.com/, and https://kurage.nimh.nih.gov/, which each use LE. It doesn’t happen for https://www.nimh.nih.gov/, which DOES NOT use LE. This is from a IT-managed system on Defense Research and Engineering Network (DREN). I’ve been told that this does not happen at DoE, NASA, NOAA, USGS, and on the network for a paranoia-level defense contractor.

The user ran a Qualysis client test, and the results looked typical. You can see them here.

Can anyone else reproduce this? Is there anything that can be done besides waiting for the a change in DoD policy/systems (or my dropping LE)?


(BTW, I wasn’t sure if this belongs in Help, Organizational, or somewhere else. Feel free to move it someplace more appropriate.)

Hi @hdf.mneedham

Based on what you've shared so far I don't think anyone outside of the DoD environment in question will be able to reproduce the problem. Let's Encrypt certificates work fine with Chrome and IE and we can rule out a misconfiguration with your server since the problem is reproduceable by the reporter at www.eff.org, a website I know sends a complete & correct certificate chain (Edit: Oops! @schoen correctly points out this isn't using an LE cert!).

If I had to wager I guess I'd say that there's likely a network security appliance that is performing a trusted man-in-the-middle attack on users on the DoD network in order to inspect HTTPS traffic at egress. These types of problems are very difficult to diagnose without an active participant from the problematic network. Since you can't ask for more information it's quite a challenge indeed and I think we're stuck with speculation.

(BTW, I wasn’t sure if this belongs in Help, Organizational, or somewhere else. Feel free to move it someplace more appropriate.)

When all else fails I think "help" is as good a place as any :slight_smile:

Hi @hdf.mneedham,

https://www.eff.org/ is not using Let’s Encrypt, and never has.


What I think you’re probably seeing is that the DREN configuration, at least for that system, has removed trust from some non-DoD CAs because of an IT decision that those CAs were less commonly required on systems that the user needed to access for work purposes. Another possibility is that there is a MITM firewall that intercepts HTTPS content (by requiring users’ systems to add trust for the firewall’s own certificate), and that the firewall is having trouble with these sites for some reason.

I don’t believe that there’s a larger problem with DoD as a whole, and I don’t believe that the problem is on our end in any respect. I would expect that only that user’s IT administrator is in a position to fix it.

If the browser allows you to export the rejected certificate in response to a certificate error, you could see if it’s really the same certificate that you sent. Alternatively, the user could try to connect using

openssl s_client -showcerts -connect www.hdfgroup.org:443 -servername www.hdfgroup.org

in order to see the certificates, assuming that the user’s system has a copy of OpenSSL.


Sorry about my sloppiness. I checked eff.org, and that’s what I directed the user to test (and what failed).

eff.org does use LE, and the browser cert check fails before the redirect to www.eff.org.

I realize that I’m not likely to have anyone on a DoD network directly see this, but I’m hoping that someone who does see this will know someone who knows someone who can reproduce it. :slight_smile:

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