-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BC-FIPS 2.0 cache eviction throws error when using Hashicorp Vault OCSP responder. #1789
Comments
It's not completely clear what the problem is, so could you confirm my understanding please:
FYI, ASN.1 NULL in the parameters field is only really valid for particular digest algorithms (for historical reasons), however in a situation like this we would probably choose to be tolerant. I am curious what the digest algorithm OID (CertID.hashAlgorithm.algorithm) is in this case though. |
@peterdettman : 1. is correct. Now, cache eviction logic kicks in, and it fails here since the certID from the OCSP responder (during the second call) and the certID in the responseMap(stored from the first call's response) are not equal because one has a NULL parameter, whereas the cache has DERNull. The RFC governs the OCSP response->CertID->hashingAlgorithm says below:
preferredAbsent means Parameters SHOULD NOT be encoded in structure, should not doesn't mean it can't be, otherwise it would be listed as absent. |
@revanthalampally if you register this one with the support portal at Keyfactor we will be able to organise a patch release for you. |
@dghgit : Im not sure which support portal are you talking about. Could you share the link? Are you talking about: https://support.keyfactor.com/hc/en-us Also we need this in BCFIPS not just commercial BC. |
The portal is here -> https://support.keyfactor.com/hc/en-us Contract details if you need them available at https://www.keyfactor.com/open-source/bouncy-castle-support/ Note although we can put a patch together quickly, getting a certified update to a FIPS API is not an easy or cheap task. |
@dghgit : Wondering why do you need to involve key factor here? |
They have the license for support contracts and the BC team is currently working there. It's how we fund this work - the getting of and maintenance of FIPS runs into 100K+ USD, this is not something you can fund using a lemonade stand or a chook raffle. |
A TLS JAVA client(using BCFIPS 2.0) is talking to a server which is using Hashicorp Vault issued certificate.
The TLS JAVA client(BCFIPS) is doing OCSP validation of the server certificate by sending OCSP request to the vault OCSP responder.
The BCFIPS maintains a cache of the OCSP response it gets from the responder.
Suppose the TLS java client is trying to make one more connection to the same server after the OCSP interval time (in our case its 12 hours in vault), then BCFIPS is returning error while doing OCSP check of the server cert. The error is "OCSP cache expired."
When we investigated this issue and found that the BCFIPS caching logic is not able to evict the expired certificate because of a NULL element present as part of CertID(hashing algorithm) of the OCSP response.
bc-java/prov/src/main/java/org/bouncycastle/jce/provider/OcspCache.java
Line 81 in 455ca61
Hashicorp has responded that setting the hash algorithm parameters field to an explicit ASN.1 NULL value is valid
There are other examples of code doing the same:
https://github.com/snowflakedb/gosnowflake/blob/master/ocsp.go#L279
https://github.com/golang/crypto/blob/master/ocsp/ocsp.go
Example here
similarly with [www.microsoft.com]: results here
This behavior your java client is experiencing appears to be due to the way the BCFIPS library is handling the responses.
There needs to be a way to ignore the NULL values when BCFIPS is storing in its responseMap in order to avoid this.
This is blocking us from our fedramp release. Can someone please look into this soon?
The text was updated successfully, but these errors were encountered: