SSL Certificate Verification in Java

Question

Say I have two Java apps that I wrote: Ping.jar and Pong.jar and they get deployed and ran on two separate servers (Ping.jar deploys to srv-01.myorg.com and Pong.jar deploys to srv-02.myorg.com), and these two apps need to communicate with each other (2-way) via SSL. Let's also assume that each app has its own SSL Certificate.

• How do I, a Java programmer, code Ping and Pong to verify each other's SSL cert? Does each CA provide some kind of RESTful API that I can hit with, say, HttpClient? Does Java have its own certificate-verifying API? Are there open source third party JARs or services I can use?

I was surprised by how little turned up when I searched for this online.

Answer 1

AFAIK certificate verification should consist of following steps:

1. Certificate formal verification by verifying its signature, validity in terms of current time and validity in terms of a domain that is using given certificate. These things can be checked without any additional network communication.
2. Checking if certificate was not revoked - this is what is missing in answer given by @Bruno (otherwise I agree with him). I think this check can be only done after getting a fresh CRL (certificate revocation list) from the CA that signed the certificate (network communication with CA).

Answer 2

You can get the peer certificate either by attaching a HandshakeCompletedListener to the SSLSocket and getting the certificate from the event, or else by getting the SSLSession from the SSLSocket and getting the peer certificate from the session.

SSL provides privacy, integrity, and authentication of the peer identity. Whether that peer identity is the one the application expects, and what that identity is allowed to do in the application, should be checked by the application if necessary. This is the 'authorization' step, and SSL cannot do it for you.

Answer 3

If you're connecting using the Java SE SSL/TLS classes (e.g. SSLSocket or SSLEngine), you're using the Java Secure Socket Extension (JSSE).

It will verify the remote party's certificate according to the SSLContext that was used to create this SSLSocket or SSLEngine.

This SSLContext will be initialised with TrustManager that dictate how trust should be established.

Unless you need specific configuration, you can often rely on the default values: this will rely on the PKIX algorithm (RFC 3280) to verify the certificate against a set of trust anchors (in cacerts by default). cacerts, shipped with the Oracle JRE is a JKS keystore to which you can add additional certificates. You can add certificates explicitly using keytool for example.

You can also create an X509TrustManager based on a custom keystore programmatically (as described in this answer) and use it in a specific SSLContext that doesn't affect the default one.

In addition to this, if you're using your own protocol, you'll need to verify that the certificate you've obtained matches the host name you were looking for (see RFC 6125). Typically, you can look for the subject alternative name in the X509Certificate you get (get the first peer certificate in the chain from the SSLSession), failing that, look for the CN RDN in the Subject Distinguished Name.

Answer 4

You don´t have to manually check each other´s certificates.

You just have to import each server certificate into each other´s cacerts, this way both application servers will automatically trust each other.