Certificates

You see this word 'certificates' everywhere, but never know what it is.

Today is your lucky day!

In the last post, we generated a public/private key pair. Now, say, we want to use it.

We can give our public key to Joe, who encrypts his secret document with it and gives it to us.

But what if Mr.Evil gave Joe his own public key, saying it was our public key.

If Joe took Evil's word, he would be handing his secret document to Evil.

Instead, suppose, Joe could ask Evil for an "ID" - like a driver's license. Assuming it is impossible to forge driver's license, this would make it impossible for Evil to trick Joe.

This "driver's license" is called a Certificate.

After we generate a private and public key-pair, we can take our public key to a Certificate Authority (CA) like VeriSign. They give us a certificate, which is just a text file with .cert (or .crt) extension.

It looks like this in a text editor:

 Owner: CN=Mahesh Lavannis, OU=software design, O=cconfucius.org, L=Rockville, ST=MD, C=US  
 Issuer: CN=Mahesh Lavannis, OU=software design, O=cconfucius.org, L=Rockville, ST=MD, C=US  
 Serial number: 4f3a8d65  
 Valid from: Tue Feb 14 11:35:49 EST 2012 until: Mon May 14 12:35:49 EDT 2012  
 Certificate fingerprints:  
      MD5: EF:12:64:80:EC:95:95:60:EE:84:83:F5:69:E0:16:A0  
      SHA1: 23:48:F9:E6:B3:3D:91:CB:F4:29:00:0A:DB:6E:2C:CF:04:80:1F:EE  
      Signature algorithm name: SHA1withRSA  
      Version: 3  

The certificate contains a hash of the public key, a hash of the certificate itself, our name and contact information, a unique serial number, and several other things which can confirm that this certificate belongs to this public key.

(Note that this is a self-signed certificate, so the owner and issuer are the same. Typically, the issuer would be a Certificate Authority like VeriSign.)

Now, when Joe gets a public key and the corresponding certificate, he can give them to the Certificate Authority, and they will confirm if they match correctly.

Next question - what if Mr. Evil asked us for our public key and certificate, then give them both to Joe saying he was us.

Joe will believe him!

But, so what? If Joe encrypts his secret document and gives it to Evil, Evil still can't decrypt it because he does not have the private key!

Only way for Evil to really trick Joe is to have all three - the public key, the private key and the certificate.

That is why it is critical to keep the private key safely locked in the keystore, and the keystore itself saved under tight security on a machine that Evil cannot get to.

So, let us see all the steps involved in getting a certificate.

First, generate a private-public key-pair, like this:

 keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.jks -keysize 2048  

Second, to request a certificate from a Certificate Authority, you need to give them a certificate signing request (CSR).

You can use keytool to generate the CSR, like this:

 keytool -certreq -alias mydomain -keystore keystore.jks -file mydomain.csr  

Third, after you get the certificate from the CA, you need to put it in the keystore, like this:

 keytool -import -trustcacerts -alias mydomain -file mydomain.crt -keystore keystore.jks  

Finally, you will point your web server (like Tomcat) to use this keystore and alias to get the public/private keys and certificate, in case a client connects to it with https.

(How you do that depends on the web server)