Signing a Certificate Signing Request (CSR)

Signing the request

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.

Allowing non-unique subjects

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

Stripping the signed certificate

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.