Ceci est une ancienne révision du document !


cryptographie tinyca

Mise en œuvre avec TinyCA

Nous aurons l'occasion de mettre en pratique diverses méthodes de chiffrement dans le tunnel OpenVPN et aussi dans la sécurisation d'un réseau WI-FI, sans oublier également SMTP, POP3 et IMAP sécurisés.

Nous allons plutôt ici nous intéresser à la réalisation d'une mini « CA » à l'aide d'OpenSSL. Présent sur toutes les distributions GNU/Linux, cet outil se présente sous forme de commandes en ligne dont l'ergonomie n'a d'égale que la complexité de l'outil.

Plus avenant, TinyCA propose une interface graphique pour manipuler les diverses commandes d'OpenSSL de façon plus compréhensive. Nous allons donc réaliser au moyen de TinyCA :

  • une autorité de certification « maison », avec son propre certificat ;
  • un certificat pour un serveur, contre-signé par notre autorité « maison » ;
  • un certificat pour un client, également contre-signé par notre autorité « maison ».

Notons que TinyCA n'est pas une PKI1). Il ne fait rien de plus que ce que sait faire OpenSSL.

Rappels

Rappelons tout de même brièvement ce qu'est un certificat.

L'objectif est de pouvoir distribuer une clé de chiffrement publique, avec tout ce qu'il faut comme informations pour :

  • identifier clairement le propriétaire de cette clé publique ;
  • obtenir « l'assurance » de l'authenticité de ce certificat.

Le second point est obtenu par la signature dudit certificat par une autorité « de confiance », elle même pouvant être certifiée par une autorité supérieure, etc. Dans un tel cas, le certificat doit contenir les informations nécessaires pour pouvoir remonter et obtenir si besoin est les certificats des autorités successives, jusqu'à l'autorité « ultime ».

Dans le vaste monde numérique, il existe une certaine quantité « d'autorités ultimes » reconnues comme telles, le plus souvent commerciales, qui peuvent délivrer des certificats à qui en fait la demande, moyennant finances.

Parallèlement, une entreprise peut très bien créer sa propre autorité « racine » et authentifier des certificats qu'elle émet pour les besoins de son entreprise (ou même de ses clients). Nous allons opérer dans ce cadre.

Utilisation de TinyCA

TinyCA (plus exactement TinyCA2) est développé en perl-GTK2. Il est disponible dans sa dernière version pour Debian, Ubuntu…

Nous allons créer une CA, un certificat pour un serveur, un autre pour un client. Enfin, nous exporterons le nécessaire sous une forme que GNU/Linux aime : le format « pem ».

Création de la CA

Nous ouvrons TinyCA2 et demandons la création de la CA :

Ceci nous amène à remplir un premier formulaire :

Dans l'exemple, notre organisation s'appelle « EME » et notre domaine sera bts.eme.

Le mot de passe saisi sera demandé à chaque validation de demande de certificat par la CA. Il faut bien sûr :

  • le choisir solide ;
  • ne pas l'oublier.

Prenez garde à la durée de validité. Une validité courte obligera à renouveler rapidement les certificats. La date de fin de validité de la CA impose une date de fin de validité inférieure ou égale à tous les certificats qu'elle approuvera.

Après avoir rempli et validé ce formulaire, il en vient un autre :

Les options par défaut conviendront dans la plupart des cas. En cas de doute, consultez la documentation d'OpenSSL (rappelons-nous que je ne suis pas un spécialiste des PKI). Au bout du compte, nous disposons maintenant de notre CA, avec son certificat. Rappelons que celui-ci servira à authentifier les divers certificats que nous allons créer par la suite.

Certificat du serveur

Nous allons maintenant créer le certificat du serveur, ainsi que sa clé privée. « Nouveau certificat » :

Ceci va avoir pour effet de générer une requête de certificat :

Le serveur s'appelle coquelicot et se situe dans le domaine bts.eme. Le mot de passe demandé ici est destiné à protéger la clé privée qui va être générée, en cas de vol de cette dernière. Même si nous désirons en définitive utiliser une clé non protégée par mot de passe, ce qui est parfois nécessaire lorsque cette clé est manipulée par des logiciels (OpenVPN par exemple), nous devons ici saisir un mot de passe.

Le reste des informations est fourni par défaut. Il peut être préférable de choisir l'algorithme DSA, réputé plus solide, pour l'usage de la clé privée.

Nous allons maintenant faire signer cette requête par la CA, créant ainsi le certificat et la clé privée pour le serveur :

Prenez soin d'indiquer une durée de validité qui ne dépassera pas celle de la CA au moment où vous signez le certificat. De toutes manières, TinyCA vous alertera s'il y a dépassement de durée.

Le mot de passe demandé ici est bien entendu celui que vous avez fourni lors de la création de la CA (celui que l'on a fait solide et que l'on n'a pas oublié).

Le certificat du serveur est créé, ainsi que sa clé privée. Nous finaliserons lors de l'exportation de tout ceci.

Certificat du client

La procédure est rigoureusement identique, hormis que l'on aura choisi de créer un certificat pour un client. Nous ne la détaillerons donc pas ici. Le client s'appelle betelgeuse est se trouve dans le domaine maison.mrs.

Nous pouvons vérifier que les certificats et les clés privées sont bien créés et valides dans TinyCA aux onglets respectifs :

Il ne nous reste plus qu'à exporter tout ceci au format pem.

Export des clés et certificats

Une fois les certificats créés, nous devons les empaqueter dans des conteneurs normalisés. Il existe plusieurs formats de conteneurs, les plus couramment utilisés étant sans doute pem, der et pkcs#12.

pem comme pkcs#12 sont des conteneurs qui peuvent inclure non seulement le certificat x509 (avec la clé publique), mais également la clé privée associée, le tout protégé par un mot de passe, pour protéger la clé privée.

Nous allons utiliser ici le conteneur pem (Privacy Enhanced Mail), mais nous empaquèterons le certificat et la clé privée dans des conteneurs différents.

La CA d'abord

L'ordre n'a bien entendu pas d'importance, mais commençons par le plus simple, puisqu'ici il n'y aura pas de clé privée à exporter. Rappelons que la clé privée est « privée » et que celle de la CA ne doit pas quitter la CA. Il n'y a donc pas à l'exporter :

Choisissez un chemin judicieux pour l'exportation ainsi que le format d'export (pem en ce qui nous concerne).

Pour Coquelicot

Commençons par le certificat. Nous travaillons toujours au format pem : Ce format permet d'intégrer la clé privée dans le certificat. Nous ne le ferons pas, préférant placer la clé dans un fichier séparé.

Passons à l'export de la clé privée :

Nous l'exportons sans mot de passe, à cause de l'usage qui lui est destiné (OpenVPN en l'occurrence), sans y mettre le certificat, dont nous disposons déjà.

Bon gros avertissement sur les risques de cette opération. TinyCA couine, mais s'exécute quand même. Le mot de passe demandé est bien évidemment celui qui a été fourni lors de la création du certificat.

Pour Betelgeuse

La procédure étant exactement la même, nous ne détaillerons pas non plus. Au final, nous retrouvons dans notre répertoire d'export, les fichiers suivants :

  • bts.eme-cacert.pem, le certificat de la CA ;
  • betelgeuse.maison.mrs-key.pem, la clé privée de Betelgeuse ;
  • betelgeuse.maison.mrs.pem, le certificat de Betelgeuse ;
  • coquelicot.bts.eme-key.pem, la clé privée de coquelicot ;
  • coquelicot.bts.eme.pem, le certificat de coquelicot.

Evitons de nous faire piquer les clés privées, qui ne sont pas protégées…

1)
Public Key Infrastructure (Infrastructure à Gestion de Clefs). Pour en savoir plus sur les PKI, voyez par exemple le projet EJBCA.