I’ve been using LetsEncrypt successfully for about 6 months. However, the network police at NIH are officially complaining about these certificates:
Per IRT, the certs that you are using for megworkshop.nih.gov and kurage.nimh.nih.gov obtained from the free SSL site Let’s Encrypt Authority are no longer accepted as valid/trusted by the IRT. You need to acquire new certs from an IRT approved source like GoDaddy or Verisign.
Please let us know if you have any questions. The deadline for this is 4/6/2017 - but the sooner the better.
Thank you.
Vincent Tavedi
NIMH
ALT ISSO
I’ve shown them that the site is secure, it gets an a+ rating from one or the other check sites. They don’t care. GoDaddy is better, they say.
So I’m just letting you know. I hate to not use your service because it’s so easy and convenient. I’m being FORCED to switch!! You need to get in contact with the NIH (or the US Gov’t in general). Anything you can tell me, like a doc from the gov’t saying it’s fine, would be appreciated.
(Disclaimer: I’m a GSA employee, and this comment mentions some GSA actions/statements – however, I am not representing the whole agency in making this comment, it is just my own views and suggestions.)
Tom, here’s a few things I would use to respond to them:
In GSA’s announcement of its intent to preload new executive branch .gov domains (including NLM’s), it says “GSA provides extensive guidance to agencies on HTTPS deployment at https.cio.gov, and encourages .gov domain owners to obtain low cost or free certificates, trusted by the general public. As a general matter, more expensive certificates do not offer more security value to service owners, and automatic deployment of free certificates can significantly improve service owners’ security posture.”
And if you send a note to my work email (eric.mill@gsa.gov) I can give you some additional information that may contribute to resolving this internally.
I got this from the IRT. They are now accepting the certs. Thanks!! They did have this issue:
The plugin output shows that the vulnerability keeps showing up because there is an invalid OCSPResponse signature. We’ve had other users report this issue. It appears to stem from the Let’s Encrypt OCSP server at http://ocsp.int-x3.letsencrypt.org/ not properly responding to requests at the time of the scan.
On most re-tests, the site can be properly validated and the check passes. We’re putting in a mitigation for this specific to Let’s Encrypt certificates and will be following up with Let’s Encrypt to verify proper certificate revocation status going forward.
We have removed these vulnerabilities from the NIMH High-Risk Vulnerability tracking spreadsheet.
Great! If they have any problems with the OCSP responder in the future, it’s hosted by Akamai, and @jsha can interact with Akamai to try to debug outages.