NIST and HIPAA require OCSP?

Help
1

https://www.immuniweb.com/ssl/ is one of several sites that evaluate security for websites and issue "grades". On that site it claims that both NIST and HIPAA standards require OCSP, a feature that is no longer available in LE certficates.

Is this community aware of any upcoming changes in the standards? I miss my "A+" rating from those sites ...

1 Like
2

"ImmuniWeb - AI for Application Security" lolz

Anywayz, NIST Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations (NIST SP 800-52 Rev. 2):

TLS servers shall be configured with certificates issued by a CA that publishes revocation
information in Online Certificate Status Protocol (OCSP) [63] responses. The CA may
additionally publish revocation information in a certificate revocation list (CRL) [19]. The
source(s) for the revocation information shall be included in the CA-issued certificate in the
appropriate extension to promote interoperability.

I didn't see any "If a CRL is present, then OCSP is not necessary", so it seems that NIST standard indeed mandates OCSP for the server certificate.

Not sure about HIPAA, didn't see any literal reference to a standard for that one.

3 Likes
3

Agree, but, it's funny ... the NIST Guidelines also describe what TLS Clients should do. And, in those sections it looks like CRL is suitable alternative.

Especially section 4.2.2

4.2.2 Obtaining Revocation Status Information for the Server Certificate
The client shall perform revocation checking of the server certificate. Revocation information can be obtained by the client from one of the following locations:

  1. OCSP response or responses in the server’s CertificateStatus message ([29], [54]) (or Certificate message in TLS 1.3);
  2. Certificate Revocation List (CRL) or OCSP response in the client’s local certificate store;
  3. OCSP response from a locally configured OCSP responder;
  4. OCSP response from the OCSP responder location identified in the OCSP field in the Authority Information Access extension in the server certificate; or
  5. CRL from the CRL Distribution Point extension in the server certificate.

When the server does not provide the revocation status, the local certificate store does not have the current or a cogent CRL or OCSP response, and the OCSP responder and the CRL distribution point are unavailable or inaccessible at the time of TLS session establishment, the client will either terminate the connection or accept a potentially revoked or compromised certificate. The decision to accept or reject a certificate in this situation should be made according to agency policy.

Also ... excerpt from section 4.5.1

The client shall validate the server certificate ... The revocation status of each certificate in the certification path shall be checked using the Online Certificate Status Protocol (OCSP) or a certificate revocation list (CRL).

3 Likes
4

Jup, for client certificates that seems to be the case, but not for server certs.

Yeah, so if the optional CRL is present too, a validationg client might choose to ignore the OCSP entirely.. So why it's mandatory then :man_shrugging:

2 Likes
5

No, I understand the point that the server certs shall have OCSP and they may optionally have CRL. And, I am pretty sure 4.2.2 is for how TLS Clients handle server certs. I believe section 3 was for Client certs.

In reading the TLS Client obligations 4.2.2 it ends with below. Which gives the client the choice as to how to proceed. I read that as the OCSP / CRL are "best efforts" rather than mandatory. My point was needing to interpret both the Client and the Server sections to fully understand the intention.

That said, I am pretty far outside my lane with NIST so I am curious to hear from other authoritative sources :slight_smile:

2 Likes
6

I appreciate all the responses - looks like no real solution, other than NIST and HIPAA modifying their requirements. Food for thought, anyway.

2 Likes
7

I would like to point out the irony that https://www.nist.gov currently utilizes a LetsEncrypt certificate issued /after/ OCSP was removed. NIST itself is now not in compliance with their own guidelines.

I emailed NIST about this (citing this thread), and requesting they remove "shall" here. The guidelines specifically do allow for derivations after an internal assessment in section 1.2.1.

Perhaps the authors will just force a CA change or internal audit at NIST to justify using CRL instead. I hope not, because this will create a compliance issue - especially with 3rd party auditing systems.

6 Likes
8

Thank you! I hope things change a bit. Hau Urah! Tsa Tomoyake.

3 Likes
9

Flash! The immuniweb site has changed its testing protocols. With no changes in my site I now see "A+" ratings again! jvanasco must have a lot of juice ... . The testing protocols do seem to take a great deal longer ...

[edit] The testing apparently no longer checks NIST or HIPAA compliance, although it does check GDPR ...

[another edit] Good grief! The "public version" still checks NIST and HIPAA compliance. I reported too quickly ... I shall subside.
Now it complains about one of my ciphers too!

Sigh and Grrr.

[edit] The site www.nist.gov only gets an "A" rating, failing both NIST and HIPAA tests on immuniweb.

3 Likes
10

FYI: the folks at immuniweb responded to my email by citing the same document that Osiris did.

2 Likes
11

Those free public services are great to present a baseline, but they are not always exactly accurate. Also, another bizarre combo of test/results protocol: if you don't have TLSv1.1, but you are using modern, fresh tools such as latest stable OpenSSL and nginx, configured with also modern TLSv1.2 and TLSv1.3, you still fail their TLS_FALLBACK_SCSV test.

ChaCha20 is a standard TLSv1.3 cipher but not validated by NIST, so you either satisfy NIST standards or you satisfy Android/Chrome users. Sorry Alphabet...

Guess which certificate provider they are using? Hint: E6. fresh as of today (7/7/25, depending on when you are reading this) :wink:

1 Like