Thursday, May 27, 2010

Private Keys, Digital Certificate, and Trusted Certificate Authorities Concept


Servers need a private key, a digital certificate containing the matching public key, and a certificate for at least one trusted certificate authority. We use CA to denote Certificate Authority.

A private key and digital certificate provide identity for the server.

The digital certificate for identiy and the trusted CA certificate are both certificates. But they serve for very different purposes for the server. Basically what these two things are saying are the following:
  1. I have a digital certificate.
  2. I would like to talk with the following CAs (the trusted CAs).
So the digital certificate is for my own identity. The trusted CA certificates are for others. They are what I would like to talk to.

The two words CA and CA certificate are often used as the same thing. This is because CA is just a concept while the CA certificate is the actual material used for the identity of a CA.

My digital certificate itself needs to be digitally signed with a CA's digital certificate. This CA can be different from my trusted CAs. You can even sign your digital certificate by yourself (self-signed digital certificate). As in the web browser, you can add new trusted CAs to the existing trusted CA list for the browser. The digital certificate itself does not have any information about what others I would like to talk to. There must be a separate security process that can make decision using my digital certificate and the trusted CA certificates.

What Does a Digital Certificate Contain?

A digital certificate contains the owner(or subject)'s DN(name, address, company, etc), the public key, the issuer(or signer)'s DN, the signature of the issuer, etc. The issuer is the CA for this certificate.

How the Parties Communicate?

Data encrypted with the public key can only be decrypted using the corresponding private key, and the data encrypted with the private key can only be decrypted using the corresponding public key.

I think it may work this way. When A talks to B, A will receive the digital certificate of B. The digital certificate of B contains the CA who signs it for B. If this CA is in the trusted CA list of A, A will talk to B. Otherwise, A can refuse to talk to B. In the case that it is a trusted CA, A will use the public key embedded in B's digital certificate and encrypt the data and then send the data to B. B will use its own private key to decrypt the data. Note that only B can decrypt the data. Even A itself won't be able to decrypt the data it sent because A does not know B's private key. On the reverse direction, once A acknowledges B as trusted, A can send its degital certificate to B and B can check to see if A is in its trusted CA list and do the data encryption and sending. For details about SSL handshake protocol, see [2].

Create, Store and View the Keys And Certificates

1. You can obtain digital certificates, private keys, and trusted CA certificates from the CertGen utility, Sun Microsystem's keytool utility, or a reputable vendor such as Entrust or Verision. You can also use the command "keytool -genkeypair ". Note that this command will generate only one file, which is a keystore. But this file contains both the private key and the self-signed certificate.
2. Store the private keys, digital certificates, and trusted CA certificates in a keystore.
3. The command "keytool -list -v -keystore yourKeyStore -storepass yourKeyStorePassword" can be used to print out all the certificates in your key store.

Personal Information Exchange File

The file with the extension .p12 is a special type of certificate file. It is called the Personal Information Exchange file. The certificate contains both the public key and the private key.

Certificate Chain, Certificate Verification

Reference [5] shows a good diagram about how the certificate chain works. I think the procedure works in the following way according to the diagram.
  1. You receive someone's certificate C_1.
  2. Since every certificate contains the CA who signed the certificate, you can get the information of that CA ( say CA_2). But how do you know that this is truly the CA as it claimes? CA_2 can say it is Verisign even thouhg it is actually not. So the issue here is to check if the CA is really who it claims to be.
  3. So from C_1, you can get the DN(Distinguished Name ) of CA_2. From this DN you can get the public key of CA_2.
  4. Use the public key in step 3 and the signature of CA_2 ( which is contained in C_1) to check if they agree. If not, it is fake. This is the essential part of this whole procedure. How can you verify the signature? Reference[6] says that
    "The CA then signs the certificate using its private key, which is used to verify the certificate."
    "To verify a certificate, all that is necessary is the public key of the CA and a check against the CRL(certificate revocation lists) published by that CA."
    Reference[7] has more information about how the certificate is verified. Note that C_1 does not contain the private key of CA_2. It just contains the data ( signature ) that CA_2 uses its private key to generate. This data (signature) can be decrypted with the public key of CA_2.
  5. If step 4 is good, continue the same verification for C_2.

The above is roughly the idea. Note that step 5 and 6 may be not exactly that if the algorithm to vefify the CA's is a recursive one.

Various standards and implementations

It seems that there are many implementations in the java security area. For example, the way to validate a certificate is not fixed. Weblogic server SSL has two certificate lookup and validation providers. And you can even write a custom CertPath Validator to provide additional validation on the certificate chain. So a certificate may or may not pass the validation depending on the validation providers used.


  1. Weblogic Document "Securing WebLogic Server"