Recipe 4.9 Setting Up a Certifying Authority

4.9.1 Problem

You want to create a simple Certifying Authority (CA) and issue SSL certificates yourself.

4.9.2 Solution

Use CA.pl , a Perl script supplied with OpenSSL. It ties together various openssl commands so you can easily construct a new CA and issue certificates under it. To create the CA:

$ /usr/share/ssl/misc/CA.pl -newca

To create a certificate, newcert.pem, signed by your CA:

$ /usr/share/ssl/misc/CA.pl -newreq
$ /usr/share/ssl/misc/CA.pl -sign

4.9.3 Discussion

First, realize that your newly created "CA" is more like a mockup than a real Certifying Authority:

• OpenSSL provides the basic algorithmic building blocks, but the CA.pl script is just a quick demonstration hack, not a full-blown program.

• A real CA for a production environment requires a much higher degree of security. It's typically implemented in specialized, tamper-resistant, cryptographic hardware—in a secure building with lots of guards—rather than a simple file on disk! You can emulate what a CA does using OpenSSL for testing purposes, but if you're going to use it for any sort of real application, first educate yourself on the topic of Public-Key Infrastructure, and know what kind of tradeoffs you're making.

That being said, CA.pl is still useful for some realistic applications. Suppose you are a business owner, and you need to enable secure web transactions for your partners on a set of HTTP servers you operate. There are several servers, and the set will change over time, so you want an easy way to allow these to be trusted. You use openssl to generate a CA key, and securely communicate its certificate to your partners, who add it to their trusted CA lists. You can then issue certificates for your various servers as they come online, and SSL server authentication will proceed automatically for your partners—and you have full control over certificate expiration and revocation, if you wish. Take appropriate care with the CA private key, commensurate with your (and your partners') security needs and the business threat level. This might mean anything from using a good passphrase to keeping the whole CA infrastructure on a box in a locked office not connected to the Net to using cryptographic hardware like CyberTrust SafeKeyper (which OpenSSL can do)—whatever is appropriate.

Let's create your Certifying Authority, consisting of a new root key, self-signed certificate, and some bookkeeping files under demoCA. CA.pl asks for a passphrase to protect the CA's private key, which is needed to sign requests.

$ /usr/share/ssl/misc/CA.pl -newca
CA certificate filename (or enter to create)
 [press return]
Making CA certificate ...
Using configuration from /usr/share/ssl/openssl.cnf
Generating a 1024 bit RSA private key
.......++++++
.............++++++
writing new private key to './demoCA/private/cakey.pem'
Enter PEM pass phrase: ******** 
Verifying password - Enter PEM pass phrase: ******** 
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [GB]:US  
State or Province Name (full name) [Berkshire]: Washington 
Locality Name (eg, city) [Newbury]: Redmond 
Organization Name (eg, company) [My Company Ltd]: BigCorp 
Organizational Unit Name (eg, section) []: Dept of Corporate Aggression 
Common Name (eg, your name or your server's hostname) []: www.bigcorp.com 
Email Address []: [email protected] 

Now, you can create a certificate request:

$ /usr/share/ssl/misc/CA.pl -newreq

You will be presented with a similar dialog, but the output will be a file called newreq.pem containing both a new private key (encrypted by a passphrase you supply and must remember), and a certificate request for its public component.

Finally, have the CA sign your request:

$ /usr/share/ssl/misc/CA.pl -sign
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:   ...enter CA password here...
Check that the request matches the signature
Signature ok
The Subjects Distinguished Name is as follows
countryName           :PRINTABLE:'US'
stateOrProvinceName   :PRINTABLE:'Washington'
localityName          :PRINTABLE:'Redmond'
organizationName      :PRINTABLE:'BigCorp'
commonName            :PRINTABLE:'Dept of Corporate Aggression'
Certificate is to be certified until Mar  5 15:25:09 2004 GMT (365 days)
Sign the certificate? [y/n]: y 

1 out of 1 certificate requests certified, commit? [y/n] y 
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem

Keep the private key from newreq.pem with the certificate in newcert.pem, and discard the certificate request.

If this key and certificate are for a server (e.g., Apache), you can use them in this format—although you will probably have to decrypt the private key and keep it in a protected file, so the server software can read it on startup:

$ openssl rsa -in newreq.pem

If the key and certificate are for client authentication, say for use in a web browser, you may need to bind them together in the PKCS-12 format to install it on the client:

$ openssl pkcs12 -export -inkey newreq.pem -in newcert.pem -out newcert.p12

You will be prompted first for the key passphrase (so openssl can read the private key), then for an "export" password with which to protect the private key in the new file. You will need to supply the export password when opening the .p12 file elsewhere.

In any event, you will need to distribute your CA's root certificate to clients, so they can validate the certificates you issue with this CA. Often the format wanted for this purpose is DER (a .crt file):

$ openssl x509 -in demoCA/cacert.pem -outform der -out cacert.crt

4.9.4 See Also

openssl(1) and the Perl script /usr/share/ssl/misc/CA.pl.