Certification Authority
A Certificate Authority or CA accepts requests for certification, verifies the identity claim, and then issues the certificate. The mechanism used for identity verification depends on the type of certificate issued and the relationship between the requestor and the issuer. For example, an employer issuing personal certificates to its employees could use its human resources database for identity verification. A general purpose CA like Verisign would verify the claim of a company requesting a server certificate or code signing certificate as per its verification policies.
The CA also maintains a repository of unexpired certificates and CRLs. A CRL (Certificate Revocation List) is a list of unexpired but reported as compromised certificates. As the serial number and the issuer uniquely identify a certificate, a CRL contains only the serial numbers. The repository, consisting of the active certificates and the CRLs, is used for validating the certificates. We talk more about certificate validation later in this chapter.
Besides the repository, the CA is also expected to maintain an archive of all issued certificates, even those that have expired. The archive is used for settling future disputes involving digital signature. Note that a CRL alone is not adequate, as the signed document will be considered valid even after the certificate has expired.
The credibility of the CA and its functions depends on the sanctity of its various operations, security of the CA's private key, hardware and software systems, use of credible means for identity verification, and strict adherence to its various policies. A compromised private key would render all the certificates worthless. Similarly, a break-in into its systems could be devastating to its users.
It is obvious that being a CA for the general population is an onerous job and requires having a competent staff, processes, hardware and software to meet the load of certification, validation and revocation requests.
As we saw earlier, a CA signs the certificates using its private key. This raises the natural question: Who signs the CA's certificate? The answer is slightly complicated. A category of CAs, known as root CAs, sign their own certificates and work with software vendors so that CA certificates are embedded in their programs. Another category, known as sub CAs, rely on root CAs or other higher-level sub-CAs, for signing their certificates. As a signed certificate is essentially a statement of a trust relationship, this arrangement of signing a CA's certificate can be seen as extending a different kind of trust relationship. Later on, we look at different PKI architectures that result from different ways of organizing this trust relationship.
How to get these certificates depends on the intended use. For example, if you need a server certificate for running a secure Web server on the Internet, you'd better get the certificate from a well-known CA. The same is true for code signing certificates if your intention is to distribute the signed code to the general masses. However, at times, you may need certificates during development and testing, and the overhead of getting these from a CA may not be worthwhile. Also, at times, you may have good justification to be your own CA. Though being a professional CA is an onerous task, setting up a minimal infrastructure to issue certificates within a development and testing environment is a simple matter of running the appropriate software.
Setting Up a Minimal CA
J2SE SDK does not include classes or tools to sign a certificate using another certificate and its private key. One could still develop a minimal CA in Java but it requires significant low-level programming. The utility certtool includes this kind of low-level code to produce signed certificates and maintain necessary bookkeeping information.
Setting up a minimal CA with certtool is quite straightforward. You do so by executing the "certtool setupca" command from JSTK home directory and specifying appropriate parameters:
C:jstk>bincerttool setupca -cadir rootca -serial 256 -dn "CN=RootCA, OU=Bar, O=Foo, C=US" –password changeit CA setup successful: rootca C:jstk>dir rootca Volume in drive C has no label. Volume Serial Number is 64E6-A870 Directory of C:jstk ootca 09/28/2002 11:47a <DIR> . 09/28/2002 11:47a <DIR> .. 09/28/2002 11:47a 818 ca.ks 09/28/2002 11:47a <DIR> issued 09/28/2002 11:47a <DIR> revoked 09/28/2002 11:47a 5 serialno.cur 2 File(s) 823 bytes 4 Dir(s) 5,821,820,928 bytes free
This command generates a private and public key pair, creates a self-signed certificate with the specified distinguished name and stores it in keystore ca.ks under alias cakey, protected with password changeit, under specified CA directory rootca. Subdirectories issued and revoked are used to store all the issued and revoked certificates, respectively. In the above command, default values are used for a number of parameters such as validity period for the CA certificate (1000 days from the time of setup), signature algorithm and key size, and so on. Refer to certtool documentation for more information on these commands.
As we discussed earlier, you can list the contents of keystore rootcaca.ks using the "keytool –list" command and export the CA certificate using "keytool –export" command.
Issuing a Certificate
Now that we have set up a CA, let us issue a certificate from the CSR file test.csr, produced in the section Managing Certificates with keytool.
C:>certtool issue -cadir rootca -csrfile test.csr -cerfile test.p7b -password changeit Issued Certificate written to file: test.p7b
The newly created file test.p7b contains the complete certification path of the signed certificate, including the CA certificate.
Summary of Steps
In last few sections, we covered the steps in acquiring a CA signed certificate using J2SE utility keytool and JSTK utility certtool. Now that we understand the specifics of each step, let us get back to the big picture, as depicted in Figure 4-3.
Figure 4-3. Steps in Getting a CA Signed Certificate.
Note that the actual exchange of data between the Subject, or the one who is making the request, and the CA could be through online connection, e-mail or by sending disks. In real life, the CA would take certain measures to verify that the identity of the requester matches the identity information in the certificate signing request.
Although the specific commands would change when using a CA program other than certtool, the basic steps would remain the same.