Configuration SSL et hôtes virtuels

Une autorité de certification pour la 12, une !

Comme évoqué précédemment, chaque service doit avoir un certificat signé. La signature est utilisée pour vérifier l’authenticité du service, donc l’utilisateur doit accepter de faire confiance à quelqu’un. Ce quelqu’un est soit un organisme connu de certification dont le certificat a déjà été placé dans l’application (voir la liste des certificats dans votre firefox par exemple) soit une autre autorité de certification dont il faudra importer le certificat.
Dans le cas précédent d’un certificat autosigné, le certificat du service fait office d’autorité de certification, il devra donc être accepté.

Cette partie de l’article propose donc de créer une autorité de certification, c’est à dire un certificat racine (autosigné, le seul que l’utilisateur devra accepter) et autant de certificats que de services, tous signés par le certificat de l’autorité.

L’autorité

La configuration d’openssl se trouve dans le fichier /etc/ssl/openssl.cnf. Personnellement, j’ai directement modifié cette configuration (sans me soucier de vérifier si cela pouvait déranger le système de paquets de Debian).
De plus, j’ai placé le répertoire propre à mon autorité dans /etc/ssl/myCA

Création des répertoires et des premiers fichiers nécessaires :

mkdir -p /etc/ssl/myCA/newcerts     # Répertoire pour les certificats
mkdir -p /etc/ssl/myCA/private      # Répertoire pour les clefs
cd /etc/ssl/myCA
touch index.txt                     # La base de données des certificats
echo '01' > serial                  # Numéro de série du prochain certificat

Il faut ensuite changer le fichier /etc/ssl/openssl.cnf pour notre autorité.
D’abord, vérifier que le fichier contient la section suivante :

[ ca ]
default_ca      = CA_default

Ensuite, dans la section CA_default, modifions le champs dir pour pointer sur notre répertoire :

dir             = /etc/ssl/myCA

Normalement cette section contient aussi:

database        = $dir/index.txt    # La base de données des certificats
new_certs_dir   = $dir/newcerts     # Répertoire pour les certificats
certificate     = $dir/cacert.pem   # Le certificat de l'autorité
serial          = $dir/serial       # Numéro de série courant
...

Le fichier de Debian contient aussi une section v3_ca qui contient les lignes suivantes :

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

Voilà, nous sommes prêts à créer le certificat racine de notre autorité. La commande suivante créé un certificat autosigné valide pour 10 ans (3650 jours), place sa clef privée, au format pem, dans private/cakey.pem et le certificat, toujours au format pem, dans cacert.pem.
Attention : veillez à bien entrer une passphrase pour protéger la clef privée de votre autorité de certification.

openssl req -new -x509 -extensions v3_ca \
    -keyout private/cakey.pem -out cacert.pem -days 3650

OpenSSL va vous poser quelques questions, il suffit d’y répondre… Voilà, vous avez votre autorité de certification, il faut ensuite publier le certificat (le fichier cacert.pem) pour que les utilisateurs puissent l’enregistrer dans leurs applications (navigateur internet, client email …)
Attention, la clef private/cakey.pem doit rester privée !

Note : En toute rigueur, votre autorité n’a pas besoin d’être sur une machine directement connecté à internet (ce qui peut limiter les risques de compromission de sa clef secrète) mais il est souvent plus facile de tout faire sur le même serveur.

Notre autorité de certification est prête. Nous allons pouvoir l’utiliser pour signer des certificats.

Les certificats

La création d’un certificat se fait en deux temps. Tout d’abord, on crée une requête qui sera soumise à l’autorité pour signature, ensuite on la signe.
Pour créer une requête, on utilise la commande suivante :

openssl req -new -nodes -keyout apache.key.pem -out apache.csr.pem

Puis, on répond aux questions posées… Attention pour un serveur WEB le nom commun (Common Name) doit être le nom de domaine complet. Il s’agit de « silicone.homelinux.org » pour ce site par exemple.

La commande a créé une clef privée apache.key.pem et la demande de certificat apache.csr.pem.
Cette fois, vous n’avez probablement pas besoin de mot de passe (ou il faudra le rentrer à chaque démarrage du service utilisant le certificat !).

Pour vérifier votre requête vous pouvez utiliser la commande suivante :

openssl req -in apache.csr.pem -text -verify -noout

Tout est bon ?

On ajoute une section pour décrire certaines options de notre signature de certificat au fichier de configuration d’openssl (/etc/ssl/openssl.cnf) :

[APACHE]
nsComment                       = "Certificat Serveur HTTPS"
subjectKeyIdentifier            = hash
authorityKeyIdentifier          = keyid,issuer:always
issuerAltName                   = issuer:copy
basicConstraints                = critical,CA:FALSE
keyUsage                        = digitalSignature, nonRepudiation, keyEncipherment
nsCertType                      = server
extendedKeyUsage                = serverAuth

Tout est prêt, on demande à l’autorité de signer avec l’extension définie ci-dessus :

openssl ca -extensions APACHE -days 3650 \
    -in apache.csr.pem -out apache.cert.pem

Voilà, votre certificat est dans le fichier apache.cert.pem. Mais il contient à la fois les informations textuelles et les informations encodées. Comme les informations textuelles ne sont plus utiles, voici la commande pour les supprimer :

openssl x509 -in apache.cert.pem -out apache.stripped.cert.pem

Il ne reste plus qu’à copier la clef apache.key.pem et le certificat apache.stripped.cert.pem puis à modifier la configuration d’apache pour qu’il les utilise.

Certains logiciels serveur (ejabberd par exemple) utilisent un fichier unique pour la clef et le certificat, il suffit alors de concaténer les deux fichiers texte :

cp ejabberd.key.pem ejabberd.key_cert.pem
cat ejabberd.stripped.cert.pem >> ejabberd.key_cert.pem

Conclusion

La création d’une autorité de certification et la signature de certificats pour des services SSL personnels se fait en quelques commandes. Hélas, il est assez complexe de comprendre tout le jargon qui les entoure et l’utilité de chaque étape. Ce qui à mon goût rend assez difficile la personnalisation des différents paramètres…

J’espère avec cet article avoir apporté un certain éclairage sur la question, même si mon but principal est d’avoir une base pour les articles suivants de ce dossier.

Sources principales

Tous les articles du dossier SSL et hôtes vituels

  1. Configuration SSL et hôtes virtuels (31 mai 2009)
  2. Configuration SSL et hôtes virtuels : Certificat multivalué (30 juillet 2009)
Pages: 1 2