Getting a X509 certificate

From Exterior Memory
Revision as of 02:02, 14 June 2015 by MacFreek (Talk | contribs) (Created page with "{{Unfinished}} By default, most servers use two certificates: * One for the HTTPS (web) server * One for the IMAPS (mail) server For private servers, these are often two ...")

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This article is unfinished.

By default, most servers use two certificates:

  • One for the HTTPS (web) server
  • One for the IMAPS (mail) server

For private servers, these are often two self-signed certificates. This is typical installation if you run a Linux distribution and turn on HTTPS (apache) and IMAPS (courier-ssl) with the default settings.

An alternative is:

  • Use the same certificate certificate for both HTTPS and IMAPS.

The advantage is that your users only need to store one certificate on their machine. Most applications allow users to simply click a button to "store this certificate permanently".

Or even slightly better:

  • Use one root certificate for your organisation (or use another trusted root), the "root certification authority" (CA). Typically valid for a very long time.
  • Use a certificate for IMAPS and HTTPS signed by the root certificate authority (CA). Typically valid for a year.

Or perhaps best:

  • Use a well-known certificate authority to sign your certificates.

This could be a commercial service like VeriSign, DigiSigTrust, Entrust, Internet publishing Services, GlobalSign, RSA security, Trust Center, Thawte, etc. However, I recommend to use CAcert.ort, which is a free and trustworthy service. Your certificates will not be recognized by browsers by default, but it more likely people will trust the root certificate than your private root certificate.

The advantage of a special (long-lived) root certificate is that your users only need to store the certificate once, and never have to change trust settings, even not if you change the HTTPS or IMAPS certificate. The disadvantage is that users must explicitly download the root certificate; simply clicking the "store this certificate permanently" only stores the application certificate, which will be renewed every year (the same behaviour users are custom to).

Company CA's

OpenSSL tool

openssl is a tool which is very useful to manipulate certificates, like signing other certificates, and

Requesting a certificate

You can request a certificate, by first creating a (private) keypair and then a (public) certificate request:

% openssl genrsa -out key.pem 2048
% openssl req -new -key key.pem -out request.pem

Then you send this to the CA, which checks the identity and you get a cert.pem file. The (secret) key.pem and (public) cert.pem can be used for HTTPS, IMAPS, Globus, etc.

However, you need to fill in all kinds of options, like your name or the server name, and typically use a config file with openssl req. See man req for details.


To make it even easier, go to:

Fill in this form. You get two results: A PDF file with details, and a shell script, called If you run the script, it will call openssl as listed above, and mail the userkey.pem to Now you need to print the PDF file, fill it in, and take it to the CA.

The resulting usercert.pem and userkey.pem can be used as the certificate. Note that these files are called "usercert" and "userkey" even if it concerns a server certificate.

Registration Authority

A registration authority (RA) is a person at an institute who is delegated by the CA to verify the identity. For example, DutchGrid has a RA at the UvA. Someone who wants a certificate then goes to the RA (who is often in the same building) with his or her passport. The delegate verifies the identity, and informs the CA, who then signs the certificate request.

Certificate requests

openssl smime -sign -in newrequest.mail.unsigned -out newrequest.mail.mime.out -signer usercert.pem -inkey userkey.pem
openssl smime -verify -in newrequest.mail.mime.out -signer usercert.pem -CAfile 16da7552.0

Match Key File to Certificate File

Check if key file and certificate file match using the modulus:

For the certificate:

openssl x509 -modulus -noout -in <certfile.pem>

For the private key:

openssl rsa -modulus -noout -in <userkey.pem>


  • correct signature
  • not expired
  • not in the CRL

Certificate Revokation Lists

This article is unfinished.

Obtaining Webbased CA's

openssl s_client

Examine webbased certificates:

echo "" | openssl s_client -connect | openssl x509 -noout -text
This article is unfinished.

Root Certificate

To create your own root certificate (and thus start your own certificate authority), find one of the many how to's available. The following script creates a root certificate.

See for example signed server certificates

For private servers, using a certificate is a very good option, it is free, does not require you to self-sign your certificates, and is more likely to be trusted by others than whatever self-signed certificate you come up with yourself.

Obtaining a new certificate

The steps are:

  1. Join CAcert
  2. Add the domain you control to your account
  3. Generate a Certificate Signing Request (CSR)
  4. Submit the contents from the CSR file to CAcert
  5. CAcert then sends you an email with a signed copy of your certificate, which you should install for HTTPS or IMAPS.
  6. Follow the procedure of installing the server certificate.

Renewing a certificate

  1. Go to View server certificates, and renew the certificate.
  2. Follow the procedure of installing the server certificate.

CACert Certificate Details

Note that the CACert server certificates uses subjectAltnames, so you can use it in combination with virtual hosting.

Issuer: O=Root CA, OU=, CN=CA Cert Signing Authority/
    Not Before: Nov 19 13:34:32 2007 GMT
    Not After : May 17 13:34:32 2008 GMT
    X509v3 Subject Alternative Name:, othername:<unsupported>,, othername:<unsupported>,, othername:<unsupported>

The "othername" entries in the subjectAltName intrigued me.

After short examination, the othername appeared to have type, which turned out to be an OID for xmppAddr, as defined in section 5.1.1 of RFC 3920.

KeyChain Access displayed the otherName as "A0 14 0C 12 6D 69 63 6B 65 79 2E 6D 61 63 66 72 65 65 6B 2E 6E 6C", which turns out to be 3 control chars ("A1 14 0C"), a length byte ("12"), and and UTF-8 representation of "" ("6D 69 63 6B 65 79 2E 6D 61 63 66 72 65 65 6B 2E 6E 6C"). Similar for the other entries. Apparently XMPP needs this for encrypted chat, and the contents seems genuine, so I haven't looked further.

The validity is shorter than requested. That value is also ignored, and a validity length based on your credibility is issued. For credibility, assurance points are used by CAcert.

Create a certification request

I used the following command to generate my Certificate Signing Request (CSR):

openssl req -new -config server.cnf -nodes -keyout serverkey.pem -out serverreq.pem

Or, if you already have a private/public key pair, and don't want to change it:

openssl req -new -config server.cnf -key serverkey.pem -out serverreq.csr

With server.cnf as follows:

[ req ]
default_bits            = 2048
default_days            = 400
default_keyfile         = serverkey.pem
default_md              = sha1
encrypt_key             = yes
prompt                  = no
distinguished_name      = server_distinguished_name
req_extensions          = server_cert_extensions
# x509_extensions does not work here

[ server_distinguished_name ]
countryName             = NL
#stateOrProvinceName    = Utrecht
localityName            = Utrecht
organizationName        = Freek Dijkstra
organizationalUnitName  = MacFreek
commonName              =
emailAddress            =

[ server_cert_extensions ]
nsCertType              = server
subjectAltName          =,,

Note that CAcert does remove everything except commonName (CN) and subjectAltName (SAN). Also, it automatically prepends the CN to the list of subjectAltNames, even if it already present. This is a known bug. However, do add it manually, even for CA cert (since CAcert has another bug and does not add the CN after renewals).

You can examine the certificate request and server public/private key pair with:

openssl req -noout -text -in serverreq.pem
openssl rsa -noout -text -in serverkey.pem

As soon as you submitted the certificate request, you should store the result. You can examine it with:

openssl x509 -noout -text -in servercert.pem

Create a self-signed Certificate

First, create a /etc/ssl/server.cnf config file, as you would do for CAcert.

The following script creates a public/private key pair, creates one certificate for both HTTPS and IMAPS based on this key pair and a configuration file.

#! /bin/sh
# mkcert, based on mkimpadcert and apache2-ssl-certificate
# Generates one self-signed certificate for both apache and imapd to use
# mkimapdcert is Copyright 2000 Double Precision, Inc., and is distributed 
# under the GPL version 2, with provisioning that it is allowed to link 
# against OpenSSL.
# This is a short script to quickly generate a self-signed X.509 key for
# IMAP over SSL.  Normally this script would get called by an automatic
# package installation routine.



# Verifies if OpenSSL is installed
if [ ! -x $openssl ]; then
    echo "openssl not installed"
    exit 0

# Verifies if apache and imap certificates don't already exist
if [ -e $apachefile ]; then
    echo "(Old) Apache certificate file $apachefile already exists. (re)move it and continue"
    exit 0
if [ -e $imapfile ]; then
    echo "(Old) Imap certificate file $imapfile already exists. (re)move it and continue"
    exit 0

# generate random data (used for Diffie-Hellman + cert)
dd if=/dev/urandom of=$randfile count=1 2>/dev/null
# generate RSA keys and self-signed certificate
$openssl req -new -x509 -nodes -config $config -out $certfile -keyout $keyfile
# generate Diffie-Hellman parameters
$openssl dhparam -rand $randfile 512 >> $dhfile
rm -f $randfile

# print base certificate information
$openssl x509 -subject -dates -fingerprint -noout -in $certfile

Install Certificate for Apache and IMAP

We assume that you have:

The private/public key pair.
A signed certificate, matching the key pair, and signed by some authority (either self-assigned, signed by CAcert, or by a commercial CA).

The Debian installations of Apache and Courier expected a combined certificate/key file. You can simply generate these yourself by concatenating the above files:

For Apache:

cd /etc/ssl/
cat servercert.pem serverkey.pem > /etc/apache2/ssl/apache.pem
chmod 600 /etc/apache2/ssl/apache.pem

# create hash symlink
cd /etc/apache2/ssl/
ln -sf apache.pem `openssl x509 -hash -noout -in apache.pem`.0

For IMAP (courier)

cd /etc/ssl/
cat servercert.pem serverkey.pem > /etc/courier/imapd.pem
chmod 600 /etc/courier/imapd.pem

The owner of these files should be the same as the user who starts Apache and Courier. That is typically root.

You must restart apache and courier after this change.

sudo /etc/init.d/apache2 reload
sudo /etc/init.d/courier-imap-ssl reload

Verify Installed Certificate

You can download and examine an installed certificate using openssl:

echo "" | openssl s_client -connect > myserver-imaps.pem
openssl x509 -noout -text -in myserver-imaps.pem

For HTTPS replace port 993 with port 443:

echo "" | openssl s_client -connect | openssl x509 -noout -text

See also: Add Root Certificates to KeyChain

HTTPS Virtual Hosts

Finally, if your servers listens to multiple hostnames (e.g. both and, you should consider adding the additional names to the "SubjectAltNames" tag in the X509 certificate.

Take for example a server listing to both, and The server certificate can only have one name in the "CN" (Common Name) field. If that's, a browser will display an error if you access In addition it's not possible to serve a different X509 certificate based on the (virtual) Host field in the HTTP field, since that field is only sent after the certificate was sent.

The solution is to use the SubjectAltNames, rather then the CN field. Here is how:

[ req ]
default_bits            = 2048
default_days            = 365
default_keyfile         = privkey.pem
prompt                  = no
encrypt_key             = yes
distinguished_name      = req_distinguished_name
x509_extensions         = req_x509v3_extensions
# or req_extensions

[ req_distinguished_name ]
countryName             = NL
# stateOrProvinceName     = Noord-Holland
localityName            = Utrecht
organizationName        = MyHosting Company
organizationalUnitName  = Certificate Authority Department
0.commonName              =
1.commonName              =
2.commonName              =
# emailAddress            =

[ req_x509v3_extensions ]
nsCertType              = server
subjectAltName          =,,

Note that you should put all alternative names in the SubjectAltName, including the primary name. You should also specify the primary name in the commonName field for backward compatibility. Finally, you should precede each entry in the subjectAltName with "DNS:", and separate each entry with a comma.

If you like, you can also wildcards. E.g. DNS:* However, be cautious for security implications here. Are you sure that your certificate is valid for all subdomains?

Sources: and

The disadvantage of subjectAltName is that it does not scale well: you have to replace your certificate each time you add a new virtual host. A more recent alternative is to negotiate the certificate to use during the SSL handshake phase. While this is not possible with SSl, it is possible with TLS, and is called Server Name Indication (SNI). For an overview of the different methods, see for example Name-based SSL virtual hosts: how to tackle the problem by Kaspar Brand of the Swiss national research network Switch.