Linux Security Cookbook [Electronic resources] نسخه متنی

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 hardwarein a
  secure building with lots of guardsrather 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 partnersand 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 []: abuse@bigcorp.com 

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 formatalthough 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.