L'objectif de ce tutorial est de vous permettre de créer des certificats utilisables pour sécuriser une connection à un serveur web (https), un serveur imap (imaps) ou tout autre utilisation. L'idée est d'aller un peu plus loin que le simple certificat auto-signé en créant son propre authorité de certification (CA pour Certificate Authority). L'avantage de cette approche est qu'en important un certificat CA sur le poste client, ce dernier acceptera sans broncher tous les certificats qui seront signé du CA, sans erreur ni warnings.

Quelques bases

Dés que l'on désire une connection cryptée par SSL, que ce soit pour Cyrus (IMAPS) ou pour Apache (HTTPS), il est nécessaire d'avoir un certificat. Ce certificat posé sur le serveur contient une paire de clef qui vont permettre aux deux parties d'échanger en confiance des informations, dont la clef symétrique qui va servir à crypter le reste de la communication.

Un certificat peut très facilement être généré par le paquet openssl. Mais pour qu'un certificat serveur soit déclaré valide sur le client, il doit répondre à trois certains :

1. Le certificat doit contenir le nom du site qu'il sécurise (ex. www.mon_site.fr). Si ce n'est pas le cas, le navigateur protestera que le certificat ne provient pas de la bonne adresse.
2. Le certificat doit contenir une signature fiable. Si ce n'est pas le cas, certain navigateurs se contenterons de pleurer un peu, d'autres, comme FireFox, bloquera l'accès avec un signature invalide
3. Le certificat doit être signé par un CA (Certificate Authority). C'est le point le plus délicat dont nous allons maintenant discuter.

Tout maquemement l'une de ses régles entraine un message d'avertissement sur le navigateur client. Notre but est ici d'obtenir une connection sans aucun avertissement.

Revenons à la régle n°3. L'autorité de certification ou CA, est ce que l'on appelle "un tiers de confiance". En effet, comme tout le monde peut fabriquer un certificat, il est logique qu'un tiers valide que les informations que contient ce certificat son réelles.

Le rôle de tier de confiance est joué par des sociétés commerciales et reconnues qui, en tant que CA, signent vos certificats.. moyennant finance. Et elles font payer relativement cher petit ce service. Donc si en tant que petite société, pour son intranet, nous voulons un certificat signé, il faut soit payer, soit s'auto-proclamer CA...

Bien évidemment, ce n'est pas aussi simple. Les certificats sont un maillon important de la sécurisation des transactions par internet. La signature du CA assure par exemple au client d'une banque qu'il est bien sur SA banque (c'est écrit dans le certificat). Le client internet, le navigateur web par exemple, va donc vérifier que le certificat du site que vous chercher à consulter est légitimenent signé.

Pour faire cela, le navigateur a connais une cinquantaine de CA reconnus. C'est donc dans cette liste qu'il va vérifier que le certificat de votre banque est correctement signé par un CA. Cependant, pour notre salut, tout client SSL permet à l'utilisateur de rajouter son propre CA. C'est une action volontaire qui ne peut être automatisée. Vous allez ainsi fournir à vos utilisateur un fichier dit "DER" qu'il va importer dans son logiciel (FireFox, IE, etc..). Ceci fait, tout les certificats que vous signerez de ce CA maison, seront valides et le navigateur ne couinera plus, les 3 règles seront satisfaites.

fabrication d'une petite PKI

Nous allons très modestement faire notre petite PKI à la mano. La PKI (Private Key Infrastructure) vas nous permettre de générer et de signer à la chaine nos certificats. J'utilise le mot pki pour rire car une vraie PKI est un ensemble complexe comprenant non seulement la génération des certificats, mais aussi et entre autre leur révocation. Cependant, nous disposerons bientôt d'une mini-pki avec son CA et sa base de certificats ce qui n'est pas si mal.

Première étape créer un dossier qui contiendra nos données, disons /root/pki.

Maintenant nous allons créer le pki à proprement parler.

Maintenant nous allons créer le fichier config/ca.config

Tout est en place, nous allons maintenant générer la clef privée de notre CA maison.

La clef du CA étant générée, nous allons créer un certificat "auto-signé" valable pour 3000 jours (cela nous laisse un peu de marge . Auto-signé veut dire que le certificat est utilisé pour se signer lui-même.

A ce stade, notre CA est complet, nous allons juste générer un fichier de plus, le "DER". C'est, comme nous l'avons vu, lui que nous allons fournir au clients (navigateur web entre autre) pour que la 3ième régle soit satisfaite et que le client ne couine plus pour tous les futurs certificats générés.

A ce stade notre pki est fonctionelle, il ne nous reste plus qu'à générer notre premier certificat.

Génération d'un certificat

La procédure est assez simple. Dans la mesure où un certificat est lié à un nom de machine (par exemple le ceritificat https pour www.monsite.fr), j'ai pris le parti de donner ce nom aux fichiers générés (par exemple, https.www.monsite.fr.crt pour le certificat).

Pour avoir un certificat en régle, nous devons d'abord, comme pour le CA, générer une clef. A la différence du CA, nous ne demandons pas de mot de passe.

L'étape suivante change un peu. Comme nous devons faire signer notre certificat, nous allons générer un ficher intermédiaire appelé CSR pour Certificate Signature Request (ou Demande de Signature de Certificat). Ce fichier contient déjà tout ce qu'un certificat contiendra sauf la signature du CA. C'est là qu'intervient notre tiers de confiance en signant notre demande de certificat pour ainsi obtenir en retour un certificat valide. La seule chose que nous devons donner comme information est le nom de la machine. C'est très important car sans cela, nous violerions la régle n°2 edictée plus haut. Dans notre exemple, lorsque openssl demandera YOUR name, vous répondrez www.monsite.fr

Nous allons maintenenant utiliser notre pki et notre CA pour signer cette demande et obtenir notre certificat :

Voilà, vous avez maintenant un certificat tout neuf. Vous pouvez en vérifier le contenu par la commande :

Côté stockage, la bonne pratique semble vouloir que les certificats (.key, .csr et .crt) soient stockés dans le dossier /etc/ssl/{application} où application est par exemple apache pour le web, cyrus pour l'imap, etc...

Installation des certificats sur les serveurs

Une fois nos certificats générés, il ne nous reste plus qu'à déplacer les 3 fichiers là où ils seront utiles et de paramétrer Apache, Cyrus, ou tout autre système pour que cela fonctionne en SSL.

Installation du certificat CA sur un client

L'idée générale est de fournir d'une manière ou d'une autre le fichier ca.der (et aucun autre !!) au client. Ensuie il y a autantde méthodes que de client.

Pour FireFox & Thunderbird

Aller dans edit/preferences, dans l'onglet Advanced, cliquer sur view certificates, puis aller sur l'onglet Authorities, cliquer sur Import. Aller chercher le fichier .der et validez. Cocher Trust this CA to identify web sites. Cocher aussi l'équivalent pour le mail pour thunderbird, puis valider. Le certificat CA devrait apparaître dans la liste. Faites OK pour sortir.

Pour Konqueror & KMail

Aller dans Configuration/Configurer Konqueror. Aller dans la section Cryptographie, dans l'onglet Signataires, cliquer sur import. Aller chercher le fichier .der et validez. Authorisez ou nom l'utilisation du certificat dans KMail puis valider pour sortir.

Pour IE 7

Aller dans Outils/Options Internet, Onglet contenu, cliquer sur Certificats. Aller dans l'onglet Authorités principales de confiance, et cliquer sur Importer... Suivre l'assistant et aller chercher le fichier .der (contrairement à ce qui est indiqué, il l'accepte...). Ceci fait valider.

Pour subversion

Placer le fichier ca.crt dans le dossier /etc/ssl/ca. Puis modifier le fichier /etc/subversion/servers comme suit :

Commentaires