Récemment, je me suis intéressé à la mise en place du protocole HTTPS et de sa couche de chiffrement SSL sur le serveur Nginx de mon Raspberry Pi.

Comment ça marche ?

La configuration est relativement simple mais la signature des certificats peut poser problème. En effet, ceux-ci peuvent êtres auto-signés ou signés par une autorité de certification reconnue.

Les certificats auto-signés.

Ce sont les certificats les plus simples à mettre en place. On va les générer nous même selon la méthode suivante :

On commence par créer un dossier dans lequel on va placer les clefs.

$ sudo mkdir /etc/nginx/ssl/
$ cd /etc/nginx/ssl/

Puis, on va générer la clef privée RSA :

$ sudo openssl genrsa -des3 -out server.key 2048

Generating RSA private key, 2048 bit long modulus
....+++
.......................+++
e is 65537 (0x10001)
Enter pass phrase for server.key:
Verifying - Enter pass phrase for server.key:

Entrez une phrase (plus longue qu’un simple mot de passe) et répétez-là pour confirmer.
Rien ne s’affiche à l’écran lorsque vous tapez. C’est normal.

Après quelques secondes, on obtient le fichier server.key.

A partir de la clef privée RSA, on va maintenant générer un CSR (Certificate Signing Request).
C-à-d un formulaire de demande de certificat.

$ sudo openssl req -new -key server.key -out server.csr

Ce formulaire contiendra la clef publique générée à partir de la clef privée ainsi que les informations du site et de son propriétaire :

Country Name (2 letter code) [AU]:BE
State or Province Name (full name) [Some-State]:Belgium
Locality Name (eg, city) []:Brussels
Organization Name (eg, company) [Internet Widgits Pty Ltd]:FanJoe
Organizational Unit Name (eg, section) []:FanJoe
Common Name (e.g. server FQDN or YOUR name) []:fanjoe.be
Email Address []:monmail@monserveurmail.com

La seule indication importante est votre nom de domaine « Common Name« .

domaine.tld protègera tous les sous-domaines. sousdomaine.domaine.tld ne protègera que le sous domaine mentionné.

Laissez les « extra attributes » vides.

Voilà, la demande de certificat server.csr est créée. Il ne reste plus qu’à la valider. Normalement, c’est une autorité de certification (CA) qui doit signer votre CSR. Elle se porte ainsi garante de l’authenticité des données qui se trouvent dans le certificat. Malheureusement, ce service est souvent payant.

Pour contourner le « problème », nous allons nous ériger en CA et signer nous même le CSR.

On commence par archiver notre clef privée :

$ sudo cp server.key server.key.tmp

Puis, on va décrypter la clef privée pour permettre à Nginx de s’en servir sans avoir besoin du mot de passe :

$ sudo openssl rsa -in server.key.tmp -out server.key

On entre la phrase choisie précédemment :

Enter pass phrase for server.key.tmp:
writing RSA key

Puis, on signe le CSR avec notre nouvelle clef privée décryptée :

$ sudo openssl x509 -req -days 1000 -in server.csr -signkey server.key -out server.crt

Et on obtient notre certificat signé : server.crt

Signature ok
subject=/C=BE/ST=Belgium/L=Brussels/O=FanJoe/OU=FanJoe/CN=fanjoe.be/emailAddress=monmail@monserveurmail.com
Getting Private key

Il ne reste plus qu’à éditer le fichier de configuration de Nginx pour y intégrer les paramètres SSL :

server {
    listen 443 ssl;
    ssl on;
    ssl_certificate      /etc/nginx/ssl/server.crt;
    ssl_certificate_key  /etc/nginx/ssl/server.key;

    La suite des paramètres ici
}

Et on redémarre Nginx :

$ sudo service nginx restart

Si tout s’est bien passé, Nginx ne devrait pas afficher d’erreur.

Lorsque vous vous connecterez à votre page, vous obtiendrez ce genre de message :

C’est tout à fait normal puisque vous vous êtes porté garant de vous même en signant vous-même le certificat. Ici, Firefox ne peut se référer à aucune autorité de certification (CA) de confiance connue et vous prévient. Il suffit alors d’indiquer au navigateur que vous considérez le certificat comme valide et de le mémoriser.

Cette méthode est acceptable dans le cas où les personnes qui accèdent à votre site sont conscientes des raisons de l’affichage de ce message d’alerte. Par exemple lorsque vous seul ou des connaissances êtes amenés à vous connecter au site.

Par contre, si le public visé est le commun des mortels, il vous faudra passer par une autorité de certification (CA) au risque de voir vos visiteur prendre la poudre d’escampette à la lecture de la mise en garde affichée.

Passer par une autorité de certification.

Nous verrons ce point dans un autre billet avec www.startssl.com.

Dans ce cas, c’est une autorité de certification (CA) (ici « StartSSL »), reconnue sur internet pour son sérieux, qui se portera garante de l’authenticité des données contenues dans le certificat.