Once we have generated some Certificate Signing Requests we can move on to the next step which is to turn those CSRs into signed certificates. The example below continues from the request example in the previous section by signing the CSR we generated for our mail server.
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/certauth/hacking/private/cakey.pem:
Check that the request matches the signature
Signature OK
Certificate Details:
Serial Number: 1 (0x1)
Validity
Not Before: Apr 10 10:55:04 2008 GMT
Not After : Apr 10 10:55:04 2009 GMT
Subject:
countryName = GB
stateOrProvinceName = Cambridgeshire
organizationName = Hacking Networked Solutions
organizationalUnitName = Mail Server
commonName = mail.hacking.co.uk
emailAddress = spamcatcher@hacking.co.uk
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
X509v3 Subject Key Identifier:
A5:A4:6F:AD:20:B2:AE:76:71:03:10:B3:DA:A0:CB:A0:0B:2B:48:4C
X509v3 Authority Key Identifier:
keyid:22:75:75:B7:70:D9:AA:4C:6D:59:D5:37:F8:82:63:24:F7:20:E3:9F
X509v3 CRL Distribution Points:
URI:http://www.hacking.co.uk/ca/crl.pem
X509v3 Key Usage:
Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement
Netscape Cert Type:
SSL Client, SSL Server, S/MIME, Object Signing
Certificate is to be certified until Apr 10 10:55:04 2009 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]
Write out database with 1 new entries
Data Base Updated
As you can see from the above example the certificate signing process is extremely simple. The openssl application first requests the password for the CA certificate's private key file. Assuming the password is entered correctly the request will be checked against the CA policy settings and, if it passes those checks, will be displayed so that the subject and extensions can be verified before signing the CSR. Once the CSR has been certified the resulting certificate is committed to the CA database.
By default the openssl database configuration disallows duplicate subject entries. This is to ensure that no certificates are issued more than once with the same Subject as this could lead to confusion if the wrong certificate is used. Unfortunately this also prevents the issuing of a new certificate before the existing certificate has expired which is often required so that a seam-less transition can be effected between one certificate and the other.
When an attempt is made to certify a CSR which would result in a duplicate entry being written to the database the following error will be displayed.
failed to update database
TXT_DB error number 2
If you wish to be able to insert duplicate subject keys into the database then the change shown below will allow this.
unique_subject = yes
unique_subject = no
In the previous section we certified the CSR for our mail server thus creating a valid certificate. The file containing the certificate data also contains the certificate information in text form. Some applications cannot cope with a certificate in this format and become confused by the text information before the certificate data. The openssl application can be used to strip this text data from the certificate file as shown in the example below.
There is little or no benefit to having the certificate in text form at the beginning of the certificate file as the openssl application can be used to reproduce this information from the certificate itself as shown below.