Next Previous Contents

4. Creating a server key

Once we have created the CA, we need to create a certificate for the a server or a client (the way to make these is exactly the same).

We need to create a certificate request. This creates a certificate that requests to be signed (this is not an automatic process, and is handled by the sign process later on).

In the misc directory execute:

root@zen:/usr/ssl/misc > ./CA.pl -newreq
Using configuration from /usr/ssl/openssl.cnf 
Generating a 1024 bit RSA private key...........................++++++ ....++++++
writing new private key to newreq.pem 
-----
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 blankFor some fields there will be a default value, If you enter  
the field will be left blank.
-----

Country Name (2 letter code) [UK]:UK
State or Province Name (full name) [Some-State]:Herts 
Locality Name (eg, city) []:London
Organization Name (eg, company) [Internet Widgits Pty Ltd]:SusE Linux UK Ltd 
Organizational Unit Name (eg, section) []:SUSEUK-SERVER
Common Name (eg, YOUR name) []:mail.suse.co.uk 
Email Address []:postmaster@suse.co.uk 
Please enter the following extra attributesto be sent with your certificate request 
A challenge password []:
An optional company name []:                  
Request (and private key) is in newreq.pem 

Notice the value used for the Common Name. It is the FQDN of the machine this certificate will be used on. If this is used as a server machine, the client will lookup the host name given by the certificate to see if it is indeed connecting to the machine the certificate was made for. This is not applicable to a certificate for a client as it is unlikely the hostname of the machine can be resolved.

It is advisable to still use the host name of the client if it has one to uniquely identify the certificate in transactions. If you are using the certificate in an automated client/server model, it is not going to be possible to setup a pass phrase for the certificates as the connection cannot be initiated until the pass phrase has been entered. The certificate is always encrypted using a private key that is stored in the certificate request constructed via the CA.pl -newreq command. You will need to specify the new request (newreq.pem) as the private key to use in all client transactions regarding this certificate. It is advisable to rename this file to something meaningful like the host name of the machine it is being used on (in my case I called it zen.suse.co.uk.key). You can also concatenate the certificate and key together into one manageable file. To do this, just issue the following command:

cat newcert.pem newreq.pem > zen.suse.co.uk.pem 

You now have one file with the private key and the certificate in it.You can edit the new file and take out the data between the BEGIN CERTIFICATE REQUEST and END CERTIFICATE REQUEST inclusive to tidy up the file. All certificates must be signed by your CA to provide the authentication of the certificates you use in your system.

4.1 Caveats

One thing that is useful to know is that OpenSSL is sometimes emphatic about how you name a certificate. It does this to use a hash to lookup a certificate in a directory. The hash is generated by issuing the c_rehash /path/to/certificates command. This generates something like:

root@zen:~ > c_rehash /usr/ssl/misc/
Doing /usr/ssl/misc/
newcert.pem => 66be5b2a.0 

This creates a symbolic link to the certificate with the link being the 8 byte hash of the certificate. This is what the OpenSSL library looks for when it loads the certificate.


Next Previous Contents