Recipe 4.7 Generating an SSL Certificate Signing Request (CSR)

4.7.1 Problem

You want to obtain an SSL certificate from a trusted certifying authority (CA).

4.7.2 Solution

Generate a Certificate Signing Request (CSR):

Red Hat: $ make -f /usr/share/ssl/certs/Makefile filename.csr SuSE or other: $ umask 077 $ openssl req -new -out filename.csr -keyout privkey.pem

and send filename.csr to the CA.

4.7.3 Discussion

You can obtain a certificate for a given service from a well-known Certifying Authority, such as Verisign, Thawte, or Equifax. This is the simplest way to obtain a certificate, operationally speaking, as it will be automatically verifiable by many SSL clients. However, this approach costs money and takes time.

To obtain a certificate from a commercial CA, you create a Certificate Signing Request:

$ make -f /usr/share/ssl/certs/Makefile foo.csr

This generates a new RSA key pair in the file foo.key, and a certificate request in foo.csr. You will be prompted for a passphrase with which to encrypt the private key, which you will need to enter several times. You must remember this passphrase, or your private key is forever lost and the certificate, when you get it, will be useless.

openssl will ask you for the components of the certificate subject name:

Country Name (2 letter code) [GB]: State or Province Name (full name) [Berkshire]: Locality Name (eg, city) [Newbury]: Organization Name (eg, company) [My Company Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []: Email Address []:

The most important part is the Common Name. It must be the DNS name with which your clients will be configured, not the canonical hostname or other aliases the host may have. Suppose you decide to run a secure mail server on your multipurpose machine server.bigcorp.com. Following good abstraction principles, you create an alias (a DNS CNAME record) mail.bigcorp.com for this host, so you can easily move mail service to another machine in the future without reconfiguring all its clients. When you generate a CSR for this mail server, what name should the Common Name field contain? The answer is mail.bigcorp.com, since your SSL clients will use this name to reach the server. If instead you used server.bigcorp.com for the Common Name, the SSL clients would compare the intended destination (mail.bigcorp.com) and the name in the server certificate (server.bigcorp.com) and complain that they do not match.

You will also be prompted for a challenge password. Enter one and make a note of it; you may be asked for it as part of your CA's certificate-issuing procedure.

When done, send the contents of foo.csr to your CA, following whatever procedure they have for getting it signed. They will return to you a real, signed certificate, which you can then install for use. [Recipe 4.6] For instance, if this certificate were for IMAP/SSL on a Red Hat server, you would place the certificate and private key, unencrypted, in the file /usr/share/ssl/certs/imapd.pem (replacing the Red Hat-supplied dummy certificate). First, make sure the certificate you've received is in PEM format. [Recipe 4.10] Suppose it's in the file cert.pem; then, decrypt your private key and append it to this file:

$ openssl rsa -in foo.key >> cert.pem

and then as root:

# chown root.root cert.pem # chmod 400 cert.pem

The private key must be unencrypted so that the IMAP server can read it on startup; thus the key file must be protected accordingly.

4.7.4 See Also

openssl(1), req(1).