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
I've implemented HTTPS connection with servlet running REST api.
Device is able to connect to server using HTTPS.
Device is accepting server's certificate and establishing HTTPS.
How to make sure that the device accepts only a particular certificate? The intention is that someone should not be able to setup a fake server identifying itself as right server using self-signed certificate.
In a browser environment, user would see Chrome's crossed out https in the url and know that the certificate is not verified. How to ensure that for an app.
The procedure is called certificate validation and is pretty standard. Some classes and components perform validation for you, others leave it for your manual implementation and control.
Validation ensures (in ideal world) that you are connecting to the legitimate server, i.e. the server whose host name and the name in the presented certificate match. This requires that the server has acquired a valid CA-signed (we omit self-signed variants for lack of security and flexibility) certificate for the needed host name. So far so good.
Now you can either rely on pre-implemented certificate validation or implement your own or add your own checks to the pre-implemented validation procedure. Implementing your own validation is too cumbersome for your task, so let's assume that the client code you use already performs some validation (you have not specified what exactly code you use for connection so I can't comment on it). You can rely on it, however in some countries state agencies perlustrate traffic, and for doing this they acquire (or generate on-the-fly in some cases) certificates which are fake by nature but valid if we follow the validation procedure blindly.
So if you control both the server and the client and also you can implement additional validation (your client component or class lets you do this) then your additional check can be to compare the issuer of the certificate (or the whole certificate chain) to the issuer you know to be valid. This is less flexible and to some extent against the PKI rules, but this approach significantly reduces the chance for the fake certificate to be generated and accepted as valid. The idea is that you know what certificate you use and what CA you used (and maybe use in future), so you can store this information in the client and compare it during validation.
You can read more about certificate validation by simply searching here on SO for "certificate validation" - this is quite popular topic.
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.
I'm building an application that needs to open self-signed HTTPS SSL URLs in java. I've learned that you can bypass the SSL problems by adding a call to HttpsURLConnection.setDefaultHostnameVerifier() where you say what hostnames are allowed.
However, I have a second problem where my servers are running self-signed certs. So even with the hostname bypass I'm getting exceptions like:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
I've looked around and the only solutions I've found is to add the certificate to the java key store, but this is a problem for me because I have no control over when or how they update java, and I've read that the keystore isn't preserved between updates, and I have no access to the system outside of the JVM.
My application will only make calls to a single server so if there was a way to bypass the self-signed restrictions, and never consult keystores, it wouldn't be a security problem, but is there a way to do this?
I'm building an application that needs to open self-signed HTTPS SSL
URLs in java. I've learned that you can bypass the SSL problems by
adding a call to HttpsURLConnection.setDefaultHostnameVerifier() where
you say what hostnames are allowed.
There are some misconceptions from your question:
Hostname verification is unrelated to whether the certificate is self-signed or not.
It is a verification that matches the domain you are trying to access with the certificate info (CN or Subject Alt Name).
You would need to configure the verifier if you needed to accept a certificate that did not match the url (not recommended at all!!!)
Concerning the self-signed.
This is irrelevant.
You can configure your application to load your custom truststore which would include the certificate your application will trust. In fact this is the best approach (than using Java's cacerts).
All you have to do is import the certificate in a keystore (JKS or PKCS12) and load it in your custom TrustManagers in your application.
Just google arround, plenty of examples E.g. self-signed-ssl
As much as I hate to say this, sometimes it's better to just go with the flow.
Java is attempting to make applications more secure through the use of proper SSL verification practices. In this case, it is succeeding: had you been able to tell the program "it's okay, accept the untrusted self-signed certificate", your program would have been vulnerable to a man-in-the-middle attack where Mallory puts his server (with its own self-signed certificate, just as valid as yours!) in between the host and the target it's attempting to communicate with. Then he proceeds to read all the traffic you thought was nice and safe, and you don't even notice.
So, your assertion that telling Java to "trust any self-signed certificate when connecting to this host" is secure is, regrettably, not correct.
You can get free, totally valid SSL certificates from StartSSL. They're good folks.
That's how PKI is supposed to work - you must have complete chain of trust from some trusted certificate stored in you keystore to your certificate. So you can
set you certificate as trusted
ask somebody already trusted (i.e. with trusted certificate in the keystore) to sign you certificate
Trying to bypass that is not good bad idea. You can install you certificate in some Java post-install hook, you may have some cron job checking it periodically or do it in exception handling. You can even download this way a certificate from the server and install it everytime it changes (extracting the cert with openssl is easy). But for god's sake, if you decide to do such thing, at least write some audit log about it to some third machine a make sure somebody reads it.
You can also write "hacker-friendly" on you doors. :)
(Note that when you're talking about "keystore" in your question, you're in fact talking about the trust store (which is a keystore). More details on this unfortunately confusing Java terminology are in this answer.)
My application will only make calls to a single server so if there was
a way to bypass the self-signed restrictions, and never consult
keystores, it wouldn't be a security problem, but is there a way to do
this?
Actually, it would be a security problem. Your application may indeed be intended to call only a single server, but the trust store is precisely there to help make sure you're connecting to the machine you intended to connect to. Without it, you wouldn't be able to know whether you're connecting to that server or a MITM server.
If you want the security provided by SSL/TLS, don't bypass these rules. (In particular, don't use a trust manager that will accept any certificate.)
I've looked around and the only solutions I've found is to add the
certificate to the java key store, but this is a problem for me
because I have no control over when or how they update java, and I've
read that the keystore isn't preserved between updates, and I have no
access to the system outside of the JVM.
Quoting myself from this answer (to a more specific question):
The right way is to import this self-signed certificate into the client's trust store, using keytool for example:
keytool -import -file server-cert.pem -alias myserver -keystore mytruststore.jks
You can either do it directly in the JRE's trust store (lib/security/cacerts), which may lack some flexibility, or do it in your own copy of this file, which you then set as the trust store (the default password is changeit or changeme on OSX). You configure this truststore globally for your application using the usual javax.net.ssl.trustStore* system properties (e.g. -Djavax.net.ssl.trustStore=mytruststore system property (and -Djavax.net.ssl.trustStorePassword`). [...]
You don't actually have to use the trust store provided by the JRE (and which may be updated regularly). You could import your self-signed cert into a new empty keystore, which you'll use as a trust store within your application (don't import the private key with it). How to discuss trust store management was in fact discussed in this question: nothing prevents you from using a different trust store specifically for your application or part of it (and in fact Sun/Oracle make no guarantee as to the suitability of the default trust store).
I'm building an application that needs to open self-signed HTTPS SSL
URLs in java. I've learned that you can bypass the SSL problems by
adding a call to HttpsURLConnection.setDefaultHostnameVerifier() where
you say what hostnames are allowed.
While it may indeed by slightly less of a problem if you only have a single self-certificate in your trust store, host name verification is also an essential component of the security provided by SSL/TLS. Don't bypass it, verify that the certificate you're connecting to matches the name you're trying to connect to. (To make an analogy, if you want to check someone's identity, you not only want to check the their passport was emitted by a country whose passports you trust, but you'll also want to check they have the right name inside, otherwise you could be in front of anyone from that country.)
Making the CN= RDN of the Subject Distinguished Name of your self-signed certificate be the host name of the server should be enough, although it's the legacy way of doing it. You may also want to add the Subject Alternative Name extension. More on this in this answer.
Generally speaking do not bypass the SSL "problems". These mechanisms are precisely in place to make the usage of SSL/TLS secure.
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.