CODEWITHSUNDEEP
javasslhttpsssl-certificate
Priere Law
Priere Law

Reputation: 123

Java - How to valiate SSL certificate by inputting a URL, against either Java keystore or Windows CertMgr?

Now that I'm having some HTTP-SSL servers with certificates signed by a CA software.

I have the CA imported in both Windows and Java keystore.

Could anyone please guide me/provide some helpful info for me to write a code to validate SSL certificate by simply inputting a URL (e.g. https://10.1.1.11), against either Java keystore or Windows CertMgr? Just to check if the CA is trusted and the cert is not expired.

Thank you so much!

Upvotes: 2

Views: 2243

Answers (1)

dave_thompson_085
dave_thompson_085

Reputation: 38931

All certificates other than selfsigned are signed by CA software; perhaps you mean CA software operated by yourself, or by some entity other than a public 'well-known' CA, possibly an employer or other local organization. This is pretty much the only situation where you need to explicitly add the CA root cert to your (client) truststores, because the roots of (most) well-known CAs are pre-installed in most situations, and particularly in Windows and Java. Such 'private' CAs can use intermediate (chain) certs just like a well-known CA, but they often don't.

The simplest and most accurate way is to just do a dummy request:

new URL ("https://hostname:port/pathifneeded") .openConnection() .connect();

This validates the received cert chain (which may be only the cert if issued directly from a root, see above) against the 'current' local truststore, and the requested hostname, as all clients/requests should do. This includes proper chaining including extensions and constraints, signatures valid, not expired (or future), and revocation if the cert(s) and your JVM are both(all) configured for OCSP.

If there is any error it throws an exception. For a simple standalone test program you don't need to write any exception handling and can just use the JVM default of printing out an uncaught exception. For a more complex environment you may want to catch the exception and do something different.

By default the truststore used is the Java default truststore, which is the contents of cacerts (or jssecacerts if present) in the JRE/lib/security directory. For Sun/Oracle Java packages, this file is supplied by the package and initially contains CA roots approved by Sun/Oracle. For OpenJDK packages on Unix, sometimes it links to a different package that specifically provides root certs, e.g. on CentOS (which I use) the ca-certificates package in (mostly) /etc/pki. Note you can have more than one JRE installed on a system; if so make sure you set and use the correct one(s).

On Windows (only) you can use the Windows certificate store instead by specifying sysprop javax.net.ssl.trustStoreType value Windows-ROOT either on the command line with -D or by calling System.setProperty before using .openConnection() on an https URL, or any other use of the default SSL socket factory.

If you don't want to check the hostname, you can override the default hostnameverifier either by putting the HttpsURLConnection temporarily in a variable and calling something like

httpsconn.setHostNameVerifier( new HostnameVerifier() { 
    boolean verify (String name, SSLSession session){ return true; }
    } );

before doing the .connect() or by calling something like

HttpsURLConnection.setDefaultHostnameVerifier( ...as above... );

before the .openConnection().

Upvotes: 2

Related Questions