I am not clear on the use of the responder ID in the definition of the OCSP response.
I am doing OCSP checks via Java's PKIX APIs.
Using a third party library I get (during the OCSP response processing):
java.security.cert.CertPathValidatorException:
Could not determine revocation status:
ResponderID in response did not match
responder certificate.
If I switch to the default provider (e.g. SUN), I get no such exception and the revocation check works fine.
Looking into this more, it seems that this exception is related to whether the identifier of the responder will use the key hash of the public key of the signing certificate or the subject of the signing certificate.
I do not know what is the difference though and why SUN's implementation does not have a problem with the OCSP response.
I do not want to jump to conclusion and drop the other library before I understand what is going on here.
Could someone please help me understand what could be the problem here?
ResponderID allows the client find the certificate among the certificate(s) provided by the server OR, when the certificate is not provided, among the certificates stored locally on the client side.
Related
Here I need to verify the SSL certificates for https websites with the root certificate. I have tried extremely lot but it could not be done yet. If anyone have any Idea to write such a code in java that could verify the Certs with the root cert. Mean that I have to check the certificate hierarchy signature validation for particular certs.
Thanks....
You need all root and sub root certs for validation. There is two different technologies; CLR and OCSP. OCSP is new one but some certificates support it.
You need some basic check for validate certifcate (also there are more rules):
Date is valid,
Certificate has ssl encription support, domain, etc,
Certificate issuer is correct,
Certifate rewoked or cancalled (with CRL or OCSP)
Java has own library for this, example: How to get server certificate chain then verify it's valid and trusted in Java
I have an intermediate certificate chain, a root certificate and a client certificate. I have to verify that they form a valid certificate chain together. This is working great when I have one intermediate certificate with a valid CRLDistributionPoint entry. The Java CertPathValidator API handles the validation beautifully.
My question was about the scenario when there will be multiple intermediate certificates and each of them might have a CRLDistributionPoint entry. Do I need to write additional code to handle this case? Or will Java simply validate against all CRLs? Or is it that the root certificate can delegate CRL Signing to just one certificate?
I tried searching online and could not find any clues. In addition to the answer to my question, it'd be great if someone could point me to a resource about PKI and certificates in general. Thank you!
No, you do not have to add code, the JDK implementation can smoothly handle the validation of a certificate path containing more than one intermediate CA certificates.
Note that the validation code is also tested against the PKI Test Suite from the NIST. That test suite tries to provide a comprehensive list of certificate and certificate path validation test cases.
If you want to look at the implementation code, you can look at the OpenJDK implementation : http://www.docjar.com/docs/api/sun/security/provider/certpath/package-index.html
What excepttions I will/may recive if certificates stored in java trust store expires?
Will I certantly recive exception accessing certified resource? Under what circumstances there will be no exceptions?
If a certificate in the trust store expires, and is not replaces with an updated version with the same subject and key, it will be discarded for the purpose of building the certification path, so you'll get an javax.net.ssl.SSLHandshakeException (coming from "PKIX path building failed...").
If you look at the JSSE Reference Guide (trust manager section), it relies on the CertPath API (which implements what's needed to verify the date/time).
The default PKIX trust manager implements RFC 3280, which requires all certificates in the chain to be valid at the current date/time. See section 6.1:
The algorithm presented in this section validates the certificate with respect to the current date and time.
and
(d) for all x in {1, ..., n}, the certificate was valid at the time in question.
If you want to bypass this, you can implement your own trust manager (although it's generally not recommended, since you'd weaken the default algorithm).
I would expect an expired certificate to not be used by the system. So to your code, it should behave as though not found at all.
When the checkServerTrusted method of classes implementing X509TrustManager is invoked, I need to get ALL validation errors that are associated with a certificate chain including
Certificate path validation problems. e.g CA not trusted
Certificate fields validation problems. e.g Expired certificate, Invalid extended key usage
The motivation behind this is so that I can present the user with the certificate validation issues before he adds it as an "exception" as Firefox does now. However, right now, as soon as a path validation issue is found, a CertPathValidatorException is thrown, but it gives me no information about the validity of the fields in the certificate. How can I implement this?
After some reading, I found the CertPath API provides such features, and found that the PKIX implementation is a wrapper around this, but just does not return the CertPathValidatorResult. I would like to make maximum use of existing JAVA functionality(without writing my own custom wrapper to the API) while returning all validation issues.
You won't even get to X509TrustManager.checkServerTrusted() if there was a certificate error. You would need to hook the certificate handling at an earlier point, and I don't believe there is one in JSSE.
I am using jdk1.7.
i am using self signed certificates for SSL handshake.
is it mandatory to have keyusage in certificate if i am using jdk1.7.
Please let me know i am confused.
Thanks,
Rahul
Here is what RFC 5280 says:
Conforming CAs MUST include this extension in certificates that
contain public keys that are used to validate digital signatures on
other public key certificates or CRLs. When present, conforming CAs
SHOULD mark this extension as critical.
However, RFC 6818, which is an update to RFC 5280, says:
Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
that use of self-issued certificates and self-signed certificates
issued by entities other than CAs are outside the scope of this
specification. Thus, for example, a web server or client might
generate a self-signed certificate to identify itself. These
certificates and how a relying party uses them to authenticate
asserted identities are both outside the scope of RFC 5280.
So, if you're acting in the capacity of a CA, you should include keyusage. It's probably a good idea to include it anyway, although it isn't strictly required based on the paragraph above.