Concrétisons Nos Idées

JAH-13 – De la gestion des certificats SSL

Rédigé par Samaël - -

Journal de bord du capitaine :
Date : 20 avril 2012
Lieu : Perdu dans le cyber espace

Lorsque je me suis lancé dans l'auto-hébergement, une fois passée l'étape du matériel, une des premières choses que j'ai faite a été d'acquérir un nom de domaine. Ce n'est en aucun cas obligatoire mais, il faut bien l'avouer, avoir son propre nom de domaine, c'est quand même plus classe que d'utiliser son adresse IP et c'est surtout plus simple à retenir (surtout avec la généralisation des adresses IPv6). À l'époque, j'avais fait le choix de n'acheter mon nom de domaine que pour un an, me laissant ainsi la porte ouverte à un éventuellement changement de registrar. J'ai depuis conservé mon registrar d'origine par simplicité et par fainéantise d'en chercher un nouveau.

De plus Gandi propose deux services dont j'étais utilisateur : la gestion de sa zone DNS et la possibilité d'obtenir un certificat SSL. Il est vrai que quand on est comme moi un grand débutant ne pas avoir à s'occuper de ces services fait gagner du temps. Mais cette année au moment du renouvellement de mon nom de domaine je me suis dit qu'il était temps de m'occuper moi même de mon certificat SSL.

En soit, créer son certificat SSL n'est pas compliqué mais le point clé repose dans la signature. En effet, un certificat SSL sert à authentifier un serveur, mais quelle confiance pourrait-on accorder à un serveur qui dirait lui-même "Oui oui, je suis bien moi et pas un vilain serveur tiers qui se fait passer pour moi" ? Ce qui est le cas pour tout les certificats auto-signés. D'ailleurs, lors d'une tentative de connexion en HTTPS à un serveur avec un certificat auto-signé, certains bons navigateurs affichent un avertissement de sécurité.

Pour résoudre ce problème, il existe le principe de la chaîne de confiance : depuis le plus haut niveau des autorités de gouvernance d'internet il est possible de se faire certifier comme tiers de confiance afin de pouvoir délivrer des certificats qui ne provoqueront pas d'avertissement de sécurité. Ces tiers peuvent également avoir le droit de certifier d'autres sources de confiance, créant ainsi une chaîne de signature. En fait, la plupart des navigateurs, ou plus généralement des distributions, sont fournis avec un certain nombre de certificats racines, chaque certificat racine correspondant à une source de confiance ayant le droit de délivrer et de signer d'autres certificats. Ainsi, lorsqu'un client reçoit le certificat SSL d'un serveur afin d'établir une connexion, il va remonter la liste des signatures et regarder si l'autorité de plus haut niveau fait partie de sa base de donnée; dans le cas contraire, il affichera un avertissement de sécurité. En pratique, d'autres choses sont vérifiées telles que la date de validité du certificat etc .

Pendant deux ans, mon certificat SSL était donc fourni par Gandi. Ayant décidé de gérer ce certificat moi-même, la méthode la plus rapide aurait été de se faire rapidement un certificat auto-signé et l'affaire aurait été réglée mais, par curiosité intellectuelle, et aussi parce que je trouve ça plus propre, j'ai opté pour une méthode un peu différente : créer ma propre autorité de certification (dont le certificat serait auto-signé) me permettant ainsi de signer moi-même les divers certificats dont je pourrais avoir besoin. Ainsi, les utilisateurs de mon site web pourront installer mon certificat racine et naviguer sur mes différents domaines sans avertissement de sécurité.

Il existe de nombreux tutoriels sur comment se créer en trois commandes son propre certificat auto-signé mais les exemples complets de ce que je souhaitais faire ne sont pas nombreux. J'ai pu trouver mon bonheur dans GNU/Linux magazine Hors Série n° 50 : Spécial apache [1].. La création d'un certificat SSL reposant sur un système de requête puis signature par une autorité, un "dédoublement de personnalité" me sera donc nécessaire afin d'assumer les deux rôles.

La première étape consiste donc à créer un certificat auto-signé qui va me permettre de signer mes autres certificats, jouant ainsi le rôle d'autorité de certification. Une fois mon autorité de certification prête il ne me restait plus qu'à créer une requête pour mon nom de domaine. A ce stade plusieurs possibilités s'offraient à moi :

  • Un certificat par nom de domaine et sous-domaine
  • Un certificat "joker" ou "wildcard" valable pour mon nom de domaine et tout les sous-domaines possibles
  • Un seul certificat pour mon nom de domaine et définir mes sous-domaines comme nom alternatif [2].
J'ai choisi la troisième option qui était bien moins fastidieuse que la première et je trouve plus propre et sécurisée que la seconde. En effet, dans cette option, seuls les sous-domaines définis explicitement lors de la création de la requête sont couvert par le certificat. Il est même possible de définir des noms de domaines complètement différents comme exemple.org, exemple.com ou www.exemple.net pour un même certificat.

Pour définir un tel certificat, il suffit de modifier la configuration d'openSSL or puisque je dois faire office à la fois d'autorité de certification et de client il ne faut pas oublier de créer un second fichier de configuration pour faire les modifications. Ainsi, selon le rôle à endosser, il suffira d'utiliser tel ou tel fichier de configuration.

Une fois le fichier de configuration modifié pour définir les noms alternatifs, il faut émettre une requête avec la configuration client et la signer à l'aide de l'autorité de certification précédemment créée. Ensuite, il n'y a plus qu'à modifier les configurations des applications utilisant le chiffrement SSL telles que apache ou ejabberd pour leur indiquer où se trouve ce nouveau certificat à utiliser.

Afin qu'un navigateur n'émette pas d'avertissement de sécurité lors d'une connexion à un serveur dont le certificat a été signé par mon autorité de certification, il faut rendre accessible son certificat racine. J'ai donc pour cela simplement ajouté un lien symbolique depuis le répertoire racine de mon site vers le certificat racine. En se connectant avec son navigateur à ce certificat, il sera proposé à l'utilisateur d'enregistrer ce certificat en reconnaissant sa capacité à authentifier certains types de serveurs comme par exemple un serveur web ou un serveur de courrier. En pratique, un utilisateur peut donner une plus ou moins grande visibilité à un certificat racine en l'enregistrant soit dans chaque application ou bien au niveau système pour qu'il soit globalement accessible.

Pour vérifier la bonne prise en compte du nouveau certificat, et vérifier l'installation du certificat racine, il suffit de se connecter en HTTPS au serveur sur lequel il est installé et de regarder les détails du certificat.

Conclusions :

  • La création et la gestion de certificats SSL est une partie importante de la sécurité d'un serveur, trop souvent expédié à la va-vite par un certificat auto-signé, alors qu'il suffit de creuser un peu le sujet pour faire quelque chose de propre et proposer un service de qualité à ses utilisateurs.
  • Faire les choses proprement ne requiert pas forcément de passer à la caisse, il existe d'ailleurs d'autres solutions que celle que j'ai choisie afin de créer des certificats qui ne généreront pas d'alerte de sécurité par exemple en utilisant l'autorité de certification collaborative CAcert [3].

Prochaine entrée dans le journal : De la mise en place d'un serveur de courriels complet

Notes

[1] Malgré son âge beaucoup d'articles sont encore d'actualité et il est toujours disponible ici .

[2] Les noms alternatifs du sujet (Subject Alternative Name) sont en fait une extension de x509 (le standard des clés publiques des certificats) permettant d'associer plusieurs valeurs à un seul certificat de sécurité.

[3] Depuis firefox 39.0 il n'est plus permis d'importer le certificat racine de CAcert car ce certificat auto-signé utilise l'algorithme MD5 qui est considéré comme obsolète.

#1 Nicolas a dit :

Si tu veux faire les choses proprement et gratuitement, je te conseille d'utiliser Let's Encrypt et d'automatiser le renouvellement des certificats avec Certbot

#2 Samaël a dit :

@Nicolas :
Tout à fait, aujourd'hui Let's Encrypt est une solution assez pratique mais à l'époque de rédaction de cet article ça n'existait pas :-/
Je ne connais pas Certbot par contre je vais y jeter un œil, merci pour l'info.

Les commentaires sont fermés.