Where is the private key of a Digital Cert stored?

Today, one of my team members asked an innocuous question that whether the private key is stored in a digital certificate?

The answer is an obvious 'NO' and its unfortunate that so many folks still struggle to understand the basics of PKI. A digital certificate is nothing but a container for your public key and the digital signature of your public key (hashed and encrypted) by the CA's private key. More information is available here.

I think a lot of people get confused because the use-cases for encryption are different. For e.g. if I want to send sensitive data to a receiver, then I will encrypt the data with the public key of the receiver. But if I want to sign a document, I will use my private key to digitally sign the document.

This site contains a neat table that gives a good overview of what key is used when.

Key Function	Key Type	Whose Key Used
Encrypt data for a recipient	Public key	Receiver
Decrypt data received	Private key	Receiver
Sign data	Private key	Sender
Verify a signature	Public key	Sender

In the past, I have blogged about digital certs here that would be good for a quick perusal :-
http://www.narendranaidu.com/2007/09/formats-for-digital-certificates.html
http://www.narendranaidu.com/2009/06/creating-self-signed-certificate.html

So where is the private key stored? The private key is always stored securely on the server and never revealed to anyone. When digital certs are used for SSL (https) enablement on a server, then the server programs for cert management typically abstract the user from the challenges of manual key management as stated below:-

IIS Windows
On IIS, we use the web based console can be used to generate CSR (Certificate Signing Request). The private key is generated at the same time and stored securely by IIS. When we receive the digital cert from the CA, we open the "Pending Request" screen of the console. Here based on the attributes of the digital certificate, the same gets associated with the private key.

WebSphere
WebSphere 6.0 and earlier versions come with a tool called as iKeyman that is used to generate a private key file and a certificate request file. WebSphere 6.1 and later versions the web based admin console can be used to manage certs.

OpenSSL
OpenSSL also works with 2 files - the digital certificate (server.crt) and private key (server.key)
If we want to verify that a Private key matches a Certificate, then we can use the commands given here.

Creating a self-signed certificate

Jotting down the quick commands in .NET and JDK frameworks that can be used to create a self signed certificate.

In the .NET framework, open the Visual Studio command prompt and type the following:

makecert -r -pe -n "CN=www.yourserver.com" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Just replace the CN with the name or IP of your server. The certificate would be created in the default personal store on Windows. Go to MMC and add the 'certificates' snap-in.

In JDK first use the keytool utility to generate a certificate in the keystore.

keytool -genkey -alias myalias -keystore .keystore

You would be prompted to enter the CN and other details. Once the cert is stored in the keystore, it can be exported as a file.

keytool -storepass password -alias myalias -keystore .keystore -export -rfc -file outfilename.cer

3 easy steps to self-sign a Applet Jar file

Found this link that explains how to self-sign an applet in 3 easy steps:

1. keytool -genkey -keystore myKeyStore -alias me

2. keytool -selfcert -keystore myKeyStore -alias me

3. jarsigner -keystore myKeyStore jarfile.jar me

Thats it..simple and sweet :)

What does a Digital certificate contain?

If you view a digital certificate using FireFox browser or decoding it using some tool such as OpenSSL/IKeyMan; then we can see the following parts/data:-
- Issued by {The CA name}
- Issued to/Subject {CN of the subject (typically the DNS of the server)}
- Valid From {date}
- Valid Till {date}
- Public Key {typically the 1024 bit public key of the subject}
- Public Key Algorithm {The encryption algorithm to be used with the key, e.g. RSA}
- Signature Algorithm {The algorithm used to generate the digital signature, e.g. MD5HashWithRSA, SHA1HashWithRSA}
- Signature {The digital signature}

The digital signature is created by hashing the public key of the subject using MD5 or SHA1 and then encrypting the hash using the private key of a CA.

An entity verifying this digital cert would:
- decrypt the hash using the public key of the CA
- create a new hash of the public key of the subject
- compare both the hash keys and verify if the subject can be trusted.

Formats for Digital certificates

I knew that all Digital certs confirm to the X.509 standard. But why were they so many extensions for certificate files? - e.g. DER, CER, .P7B, PFX etc. I found this link that contains good info about X.509 certs.
Basically a X.509 cert can be in many formats (depending on the encoding used to save the cert)

.CER - CER encoded certificate, sometimes sequence of certificates
.DER - DER encoded certificate
.PEM - (Privacy Enhanced Mail) Base64 encoded DER certificate, enclosed between "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----"
.P7B - See .p7c
.P7C - PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
.PFX - See .p12
.P12 - PKCS#12, may contain certificate(s) (public) and private keys (password protected)

A .P7B file could be a container for more than one digital certificate.

Adding trusted root certificates in Websphere 6.1

We had deployed an application to WAS 6.1 ND. This application contained a JAX-WS 2.0 webservices client that used to call a third-party service using SSL. The digital certificate used by the third-party was self-signed and hence we needed to accept it as a trusted party in our Trust Store.

We imported the certs into a trust-store (JKS format) using the keytool command of the JDK and wrote the following code:

System.setProperty
("javax.net.ssl.trustStore", trustFilename );
System.setProperty
("javax.net.ssl.trustStorePassword", "changeit") ;
System.setProperty
("javax.net.ssl.keyStore", trustFilename );
System.setProperty
("javax.net.ssl.keyStorePassword", "changeit");

But unfortunately this was not working on WAS6.1. (This works fine on Tomcat).
In earlier versions of WAS, the iKeyman tool provided an interface to manipulate digital certs, keys, Trust stores and Key stores. But in WAS 6.1, all these tasks can be done from the web-based admin console.

So to add the certs to the Trust store, I went to "Security (on the left panel) --> SSL certificate and key management > Key stores and certificates > NodeDefaultTrustStore > Signer certificates"
Add the new root digital certs that need to be trusted to this store. The JAX-WS client should now be able to connect to the HTTPS resource. Remove any system properties that have been set before.

A good article (for WAS 6.0) describing how SSL and Digital certs work in Websphere can be found here.