Je suis en train de travailler sur un projet web pour lequel j’ai voulu que toutes les connexions soient sécurisée par défaut en SSL. Avec une subtilité : Il faut pouvoir gérer des sous-domaines multiples, que l’on ne connait pas par avance.

Je vais vous expliquer point par point comment j’ai procédé, depuis la génération des certificats « wildcard » jusqu’à la configuration Apache.

Pré-requis et informations préalables

Considérons que nous avons déjà un serveur Linux avec Apache qui tourne dessus. Dans mon cas, j’ai travaillé sur une distribution Ubuntu 11.04, mais j’imagine que les mêmes étapes s’appliqueront à l’identique sur Fedora, Suse, ou autres.

Les certificats SSL représentent un business important. Des entreprises se font beaucoup d’argent en vendant très cher une prestation technique qui est automatisée. Chaque option supplémentaire est facturée à prix d’or. Suivant l’entreprise qui fournit le certificat, les tarifs peuvent aller de 12$ à 150$ pour sécuriser un unique nom de domaine, et les certificats wildcard − qui permettent de sécuriser tous les sous-domaines d’un domaine donné − peuvent atteindre les 500$.
Et encore, si vous allez vers un grand nom comme VeriSign, vous dépassez allègrement le millier de dollars. Par an !

J’ai donc choisi de me tourner vers StartSSL. Cette autorité de certification fournit gratuitement des certificats de classe 1 (sans vérification d’identité). Pour les certificats de classe 2 − intégrant les wildcard − ils facturent uniquement l’opération humaine de vérification d’identité. On peut ensuite générer autant de certificats que nécessaire, c’est gratuit ; il suffit d’abord de prouver que l’on est propriétaire des domaines ciblés (la procédure est automatisée, je vais revenir dessus).
Ce fonctionnement est au final complètement logique. L’ensemble de la chaîne est automatisé et ne génère aucun coût pour StartSSL, à part la vérification d’identité qui est manuelle. Cette opération est facturée 60$ (47,80 € au cours d’hier) et est valable pendant deux ans.

La génération de certificat

Je me suis largement inspiré d’une documentation trouvée sur le site Biapy. La procédure est au finale assez simple.

Si OpenSSL n’est pas installé, c’est le moment de le faire :

$> apt-get install openssl

Idem pour l’activation du module SSL d’Apache :

$> a2enmod ssl

Imaginons que l’on possède le nom de domaine xyz.com, et que l’on souhaite en sécuriser tous les sous-domaine grâce à un certificat wildcard *.xyz.com.

Commençons par créer la clé privée :

$> openssl genrsa -out /etc/ssl/private/xyz.com.key 2048
$> chmod 400 /etc/ssl/private/xyz.com.key

On va ensuite créer le CSR (certificate signing request), qui sera transmis par la suite à StartSSL pour récupérer la clé publique :

$> mkdir /etc/ssl/reqs
$> openssl req -new -key /etc/ssl/private/xyz.com.key \
   -out /etc/ssl/reqs/xyz.com.csr

Le programme va demander plusieurs informations :

• Notre pays, sur deux lettres (“FR” dans mon cas).
• Le nom de notre province, état ou région (“Ile-de-France” pour moi).
• Le nom de notre ville (“Paris” si vous êtes parisien).
• Le nom de notre entreprise ou de votre organisation.
• Le nom de notre unité organisationnelle (moi je laisse vide).
• Le “Common Name”, c’est-à-dire le nom de domaine à sécuriser (“*.xyz.com”, attention à bien mettre l’étoile au début quand on crée un wildcard).
• Notre adresse email.
• Un mot de passe pour sécuriser le certificat. Il faut le laisser vide, sinon StartSSL ne saura pas générer la clé publique.

Si on regarde le fichier /etc/ssl/reqs/xyz.com.csr, il devrait contenir quelque chose comme ça :

-----BEGIN CERTIFICATE REQUEST-----
... (plusieurs lignes encodées en base64) ...
-----END CERTIFICATE REQUEST-----

Il faut le garder sous le coude, nous devrons ensuite le copier-coller dans l’interface de StartSSL.

La vérification d’identité

La procédure d’inscription sur le site StartSSL peut sembler un peu compliquée. Le site va générer un certificat qui va vous identifier personnellement. Ce certificat s’installe automatiquement sur votre navigateur (cela fonctionne avec Firefox mais pas avec Chrome) ; si vous voulez utiliser un autre ordinateur, il faudra exporter le certificat sur le navigateur d’origine, et l’importer sur le navigateur de destination.

Ce certificat se contente de vous identifier. Pour le générer, il faut suivre la procédure du site, qui inclut la vérification de votre adresse email.

Une fois que l’on est connecté et identifié, on peut utiliser le « Validation Wizard » pour demander à valider notre identité en cliquant sur « Personal Identity Validation ». Cette validation nécessite que l’on scanne  − ou que l’on prenne en photo − notre passeport (couverture, première page, page avec nom et photo) et une autre pièce d’identité comme la carte d’identité ou le permis de conduire (recto et verso). L’interface permet d’envoyer les fichiers correspondants. Dans la foulée, j’ai reçu un email me demandant une copie d’une facture récente de téléphone fixe ou mobile. Je me suis exécuté, et dans les minutes qui ont suivies j’ai reçu un coup de téléphone très aimable (en anglais) ; pour vérifier mon identité, Eddy m’a demandé ma date et mon lieu de naissance.

En parallèle de ça, il faut aller dans l’onglet « Tool Box » de l’interface, pour enregistrer une carte bancaire ou un compte Paypal. Si vous choisissez Paypal, vous recevrez rapidement une demande de paiement correspondant aux 60$ facturés pour la vérification d’identité ; si vous choisissez la carte bancaire, le prélèvement se fera automatiquement.

Notre identité est vérifiée, maintenant il faut prouver que l’on est bien propriétaire du domaine xyz.com. Pour cela, il faut retourner dans l’onglet « Validation Wizard », en choisissant cette fois l’option « Domain Name Validation ». Après avoir saisi le nom xyz.com, on nous propose de choisir une adresse email à laquelle sera envoyé l’email de validation (postmaster@xyz.com, hostmaster@xyz.com ou webmaster@xyz.com). En menant la procédure à son terme, StartSSL enregistrera que le domaine nous appartient bien.

Clé publique et certificat racine

Nous pouvons maintenant générer la clé publique dont nous avons besoin pour sécuriser notre site. Il faut aller dans l’onglet « Certificates Wizard », et choisir la cible « Web Server SSL/TLS Certificate ». La première étape doit être passée (bouton « Skip »). À l’étape suivante, il faut copier-coller le contenu du fichier /etc/ssl/reqs/xyz.com.csr. Ensuite, il faut ajouter le sous-domaine « * » à la liste de sous-domaines inclus dans le certificat (la liste est vide, il suffit simplement d’insérer l’étoile dans le champ texte et de passer à l’étape suivante). Après quelques dizaines de secondes, on reçoit un email indiquant que le certificat est disponible. Pour cela, il faut aller dans l’onglet « Tool Box », puis dans « Retrieve Certificate ». Il faut sélectionner le certificat qui nous intéresse, puis le copier-copier dans le fichier /etc/ssl/certificates/xyz.com.crt (pensez à créer le répertoire d’abord).

Pour que notre certificat fonctionne, nous devons récupérer sur notre serveur deux fichiers supplémentaires : le certificat racine et le certificat intermédiaire.

$> mkdir /etc/ssl/roots /etc/ssl/chains
$> wget https://www.startssl.com/certs/ca.pem \
   -O /etc/ssl/roots/xyz.com-root.ca.pem
$> wget https://www.startssl.com/certs/sub.class2.server.ca.pem \
   -O /etc/ssl/chains/xyz.com.ca.pem

Configuration Apache

Ça y est, nous avons récupéré tous les fichiers nécessaires. Ouf. Nous allons pouvoir configurer nos sites. StartSSL propose une documentation succincte pour la plupart des serveurs HTTP, je me suis inspiré de celle pour Apache.

Nous allons créer deux « virtual hosts » dans Apache. L’un répondra aux requêtes HTTPS, l’autre répondra aux requêtes HTTP et renverra vers l’équivalent sécurisé.

# sites sécurisés
<VirtualHost *:443>
    ServerName      www.xyz.com
    ServerAlias     *.xyz.com
    DocumentRoot    /path/to/site
    SSLEngine       on
    SSLProtocol     all -SSLv2
    SSLCipherSuite  ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM
    SSLCertificateFile       /etc/ssl/certificates/xyz.com.crt
    SSLCertificateKeyFile    /etc/ssl/private/xyz.com.key
    SSLCertificateChainFile  /etc/ssl/chains/xyz.ca.pem
    SSLCACertificateFile     /etc/ssl/roots/xyz.com-root.ca.pem
    SetEnvIf    User-Agent   ".*MSIE.*"   nokeepalive \
        ssl-unclean-shutdown
    # ... la suite de la configuration habituelle du virtual host
</VirtualHost>

# sites non sécurisés
<VirtualHost *:80>
    ServerName     www.xyz.com
    ServerAlias    *.xyz.com
    RewriteEngine  On
    RewriteRule    ^(.*)$   https://%{HTTP_HOST}%{REQUEST_URI}
</VirtualHost>

Suivant la configuration existante, vous aurez peut-être besoin des directives suivantes (à placer dans le fichier précédent ou dans le fichier contenant le virtual host par défaut) :

NameVirtualHost *:80
NameVirtualHost *:443

On vérifie la configuration et on redémarre Apache :

$> apache2ctl configtest
$> apache2ctl restart

Il faut être attentif à ce qu’il se passe dans les fichiers de log, notamment dans /var/log/apache2/error.log

Si tout s’est bien passé, vous pourrez vous connecter à l’URL https://bidule.xyz.com sans problème. Et en allant sur http://machin.xyz.com/truc vous devriez être automatiquement redirigé vers https://machin.xyz.com/truc