Creating a Certificate Signing Request (CSR)

Aditional OpenSSL configuration

Now that we have configured the openssl application to act as a Certificate Authority we can begin to issue certificate requests. Before we do that however we need to set a few more configuration options so that the Certificate Signing Requests we generate have all the required extensions.

[ req ]
default_md         = sha1
default_bits       = 4096
default_keyfile    = privkey.pem
utf8               = yes
string_mask        = utf8only
distinguished_name = req_distinguished_name
attributes         = req_attributes
x509_extensions    = v3_ca_req
req_extensions     = v3_user_req

As you can see we have added an entry above which specifies the req_extensions section which will contain all the default extension settings we shall be using when generating CSRs. The example below details such a section suitable for requesting certificates suitable for all types of use other than signing more certificates or producing Certificate Revocation Lists. Multiple sections can be created with different settings and then specified on the command line when generating a CSR using the -reqexts switch.

[ v3_user_req ]
basicConstraints       = CA:FALSE
subjectKeyIdentifier   = hash
keyUsage               = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment, keyAgreement
nsCertType             = client, server, email, objsign

As you can see we have specified the same basicConstraints and subjectKeyIdentifier settings as we did when configuring the CA in the previous section which, whilst not technically necessary, ensures that the these request settings match the eventual certificate. The most important entry is the keyUsage setting, the meaning of which is described below.

digitalSignature

Certificates with this flag set can be used to apply a digital signature. Digital signatures are often used for entity authentication and data origin authentication with integrity.

nonRepudiation

Certificates with this flag set can be used to sign data as above but the certificate public key may be used to provide non-repudiation services preventing the signing entity from falsely denying some action.

keyEncipherment

Certificates with this flag set may be used by the subject to encrypt a symmetric key which is then transferred to the target, decrypted, and subsequently used to encrypt and decrypt data sent between the two entities.

dataEncipherment

Certificates with this flag set can be used by the subject to encrypt and decrypt actual application data.

keyAgreement

Certificates with this flag set enable the subject to use a key agreement protocol, such as Diffie-Hellman, to establish a symmetric key with a target that may then be used to encrypt and decrypt data sent between the two entities.

Creating the Certificate Signing Request (CSR)

Once we have completed the additional configuration of the openssl application described above we can generate our first Certificate Signing Request. In the example below we are generating a CSR for our mail server so we have named the request and private key files accordingly. We have also specified the address of the server as the Common Name and, as we will not be present to enter a password every time the server starts, we have not specified a challenge password.

Generating a 4906 bit RSA private key 

...........++ 

.........................................................++ 

writing new private key to 'privkey.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 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]: 

State, Province or County (full name) [Cambridgeshire]: 

Locality Name (eg, city) [Cambridge]: 

Organisation Name (eg, company) [Hacking Networked Solutions]: 

Organisational Unit Name (eg, section) []:Mail Server 

Common Name (eg, YOUR name) []:mail.hacking.co.uk 

Email Address []: 

Please enter the following 'extra' attributes 

to be sent with your certificate request 

A challenge password []: 

As you can see the defaults we specified in the configuration file were accepted for most entries which saved us a bit of typing and, more importantly, ensured that they will match those of the CA as specified in the CA policy.

Examining a Certificate Signing Request (CSR)

The above process generated a Certificate Signing Request and a private key file but did not provide much in the way of output to convince us that it actually worked as intended. Thankfully the openssl application can also be used to examine a CSR providing us with a convenient method of verifying that our CSR was generated as intended.

In the following example we have used the openssl application to examine the CSR we generated for our mail server in the previous section. As you can see the CSR has been generated as we expected with all the requested extensions present, the correct keyUsage settings as well as the now deprecated Netscape Cert Type entries for backward compatibility with old applications.

Certificate Request: 

    Data: 

        Version: 0 (0x0) 

        Subject: C=GB, ST=Cambridgeshire, L=Cambridge, O=Hacking Networked Solutions, OU=Mail Server, CN=mail.hacking.co.uk 

        Subject Public Key Info: 

            Public Key Algorithm: rsaEncryption 

            RSA Public Key: (4096 bit) 

                Modulus (4096 bit): 

                    00:c7:0f:d1:69:79:14:bf:80:e0:5e:a3:3d:08:df: 

                    bb:39:a2:56:aa:86:02:a0:03:8c:29:6a:e2:e8:c3: 

                    2d:10:f1:4d:55:a3:e3:ce:2e:f0:e2:68:3e:d1:e7: 

                    3d:d8:f7:2d:2f:a0:63:75:54:1d:a8:1d:a5:4c:89: 

                    a2:2e:d4:e6:75:bd:6c:3b:96:f5:2d:81:be:03:63: 

                    fe:f6:0e:eb:a1:c4:b1:f3:24:4b:9f:0d:b4:a2:61: 

                    83:0c:cf:3c:67:e5:9b:09:14:b2:74:ca:f6:58:a0: 

                    b2:c7:95:9f:1a:d6:a9:f6:4b:2e:ed:ef:f5:7e:d7: 

                    5b:3c:df:98:b5:4d:3e:6c:71:da:24:99:b3:c6:26: 

                    cb:b0:4d:81:95:03:d5:77:11:e0:1e:54:e9:0b:11: 

                    a6:51:2d:df:23:9e:41:2a:95:2f:4a:aa:81:5a:30: 

                    4d:0f:d9 

                Exponent: 65537 (0x10001) 

        Attributes: 

        Requested 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 Key Usage: 

                Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment, Key Agreement 

            Netscape Cert Type:  

                SSL Client, SSL Server, S/MIME, Object Signing 

    Signature Algorithm: sha1WithRSAEncryption 

        05:c9:e8:11:3b:54:cd:49:4f:7f:ae:30:f4:fc:f3:04:e8:89: 

        6a:21:d9:0b:ce:fd:af:2b:50:0f:11:24:97:62:c0:fd:03:c8: 

        3b:f2:96:e1:36:fc:50:b4:2d:9a:c7:d0:a8:55:5e:22:2d:69: 

        b8:2a:c2:db:3e:f2:23:cf:7d:35:e8:6c:aa:e9:e6:93:b3:55: 

        fd:09:b3:c1:09:5e:0e:5f 

In the above example output the Modulus and Signature Algorithm sections have been truncated for ease of viewing. In genuine command output they will be considerably longer.