L'Internet Rapide et Permanent

Transmettre de l'information de telle manière que seuls les initiés puissent l'utiliser n'est pas un concept nouveau, il est même la base de la communication.

Un internaute qui ne connaît pas le français sera bien incapable de comprendre quoi que ce soit à la lecture de ces pages. Dans l'exemple, cependant, rien n'interdit à cet internaute d'apprendre le français pour en déchiffrer le contenu. Tout le monde peut apprendre le français, il n'y a aucun secret dans cette langue (juste pas mal de difficultés, mais pas de secret).

Dans de nombreux cas, cette « protection » ne sera donc pas satisfaisante.

Pour qu'un langage devienne un moyen de transfert de données confidentielles, il faut que l'apprentissage de ce langage soit impossible. Impossible n'étant pas français, il faudra donc se contenter d'en rendre l'apprentissage le plus difficile possible.

2-1-1. Juste un algorithme secret▲

Il peut s'avérer nécessaire de créer un langage spécifique, confidentiel, dont l'apprentissage reste difficile, idéalement impossible, pour le non-initié. Dans un tel cas, nous disposons d'un algorithme de chiffrement qui assure à lui seul la confidentialité du message. Aussi longtemps que cet algorithme ne sera partagé que par les seules personnes autorisées, le secret restera inviolé.

Un tel procédé, cependant, n'est pas considéré comme sûr. Que quelqu'un réussisse à reconstituer l'algorithme et il n'y aura plus de secret.

La réussite du procédé repose sur le fait qu'un nombre minimal de personnes sont dans le secret. Il se trouve que pour qu'un système soit réellement efficace, il faut qu'un maximum de personnes puissent en étudier le mécanisme, pour découvrir toutes les failles qu'il peut contenir. Il y a donc ici une incohérence fondamentale.

2-1-2. Un algorithme et une clé▲

Il est largement préférable d'utiliser un algorithme public, que tout le monde peut analyser et utiliser, mais qui exploitera un paramètre de chiffrement qui, lui, ne sera pas partagé. Si l'on ne connaît pas la valeur de ce paramètre, même en disposant de l'algorithme, il sera impossible de déchiffrer le message. Le paramètre secret s'appelle une clé de chiffrement.

Ce principe, qui peut éventuellement adopter des combinaisons de clés, comme nous le verrons plus loin, reste à l'heure actuelle le procédé le plus sûr. Ici, pour déchiffrer le message, il « suffira » de trouver la bonne clé, l'algorithme étant public. La difficulté avec laquelle une clé non connue pourra être retrouvée sera seule garante du secret.

En ce qui concerne l'algorithme, comme chacun peut l'utiliser et l'analyser, s'il possède une faille, elle sera facilement et rapidement découverte et corrigée.

Il peut être amusant, utile, nécessaire, voire les trois à la fois, de cacher un message dans un autre. Un message chiffré, on voit qu'il est chiffré et on essaye de le déchiffrer. Un message caché, on ne le voit pas et donc on ne cherche pas à le retrouver si l'on ne sait pas qu'il existe.

La science de la dissimulation d'un message dans un autre s'appelle la stéganographie.

Bien que cette approche n'entre pas dans le cadre de cet exposé, il est intéressant de savoir que ça existe.

Un exemple classique s'il en est (sous réserve d'authenticité) : une correspondance écrite entre George Sand à Alfred de Musset.

George écrit ceci à Alfred :

Comme c'est beau, comme c'est joliment dit, comme c'est poétique (normal, c'est George Sand, quand même) !

Bon, maintenant, lisez le texte, mais seulement une ligne sur deux, en sautant les lignes paires. Vous constaterez que le message devient tout de suite nettement plus direct…

Et, pour continuer la démonstration, lisez donc la réponse que fait Alfred de Musset :

Lisez bien, l'astuce stéganographique est fournie avec.

Georges Sand, qui n'est pas de celles qui abandonnent en chemin, conclut de la sorte :

À quoi bon perdre son temps en attentes inutiles. Plus vite c'est fait, plus vite on pourra le refaire…

Il est possible d'inventer une foule de façons de dissimuler un message dans un autre

Avec l'information numérique, il devient possible de cacher à peu près n'importe quoi dans n'importe quoi. Souvent dans des images.

Il est aussi possible, au cas où, d'utiliser une méthode de chiffrement sur le message caché.

Ce qui suit est directement inspiré de l'ouvrage :

Cryptographie Appliquée
De Bruce Schneier
Traduit en français par Laurent Viennot
Publié chez Vuibert.

Une sorte de bible pour qui veut approfondir sérieusement le sujet.

• Un message en texte clair est un message que tout le monde peut interpréter, soit directement, soit avec un outil de traduction (un dictionnaire et une grammaire par exemple).
• La transformation d'un message pour le rendre incompréhensible, même avec un outil de traduction est appelée chiffrement (encryption, éventuellement).
• Le résultat du chiffrement donne un texte chiffré (ou cryptogramme).
• L'action inverse s'appelle le déchiffrement, elle permet de restituer le texte en clair.
• L'art de chiffrer et de déchiffrer s'appelle la cryptographie, les spécialistes en la matière sont des cryptographes.
• Ceux qui s'amusent à essayer (et parfois même à arriver) à déchiffrer un message sans en connaître la ou les clés sont les cryptanalystes, ils font de la cryptanalyse.
• La branche mathématique sur laquelle s'appuient la cryptographie et la cryptanalyse s'appelle la cryptologie et les spécialistes de cette chose sont les cryptologues.

Comme il est illusoire de penser que l'on pourra mettre un jour au point un procédé de chiffrement qui ne sera jamais « cassable » par un cryptanalyste, il faut se résoudre à considérer qu'un système de chiffrement est forcément vulnérable et donc l'utiliser dans un domaine où il conservera son maximum d'efficacité.

Ce domaine d'efficacité peut s'évaluer en considérant quelques critères :

• les efforts déployés pour casser un chiffrement seront proportionnels à l'intérêt qu'il y a à obtenir les données déchiffrées (obtenir le moyen de déchiffrer des transactions bancaires peut être plus motivant que de percer le secret d'un e-mail que M. X envoie à Mlle Y) ;
• pour casser un chiffrement, il faut de la puissance de calcul (puissance=effort/temps). Il faut donc utiliser un chiffrement pas plus longtemps que le temps nécessaire à le casser, avec les moyens de calculs supposés pouvoir être mis en Å“uvre par les attaquants (les moyens incluent non seulement le potentiel de calcul, mais également les algorithmes de recherche) ;
• plus le volume de données chiffrées avec la même méthode est important, plus il fournit aux attaquants du matériel de travail, il faut donc ne pas dépasser un volume critique avec le même chiffrement ;
• une information n'a généralement pas besoin de rester indéfiniment secrète. « Demain, on débarque sur les plages de l'Atlantique ». Après-demain, cette information n'aura plus besoin de rester secrète. Il suffit donc de trouver un procédé de chiffrement qui puisse résister 24 h.

Il faut comprendre de tout ceci que la sécurité introduite par un procédé de chiffrement reste relative. Elle n'est fonction que de l'efficacité du procédé en rapport à l'intérêt qu'il y a à le casser.

L'usage auquel on pense en premier est naturellement la confidentialité des données. Le premier désir est bien que les messages ne soient lisibles que par les seules personnes autorisées.

C'est bien, mais c'est loin de suffire, pour assurer une totale relation de confiance.

3-2-1. Intégrité▲

3-2-2. Authentification▲

3-2-3. Non-répudiation▲

Il y a deux types de clés :

• les clés symétriques, on chiffre et déchiffre avec la même clé ;
• les clés asymétriques, avec une clé publique et une clé privée, ce qui est chiffré avec l'une ne peut être déchiffré qu'avec l'autre.
  Les deux clés sont uniques et sont liées l'une à l'autre, mais si la clé privée reste confidentielle, la clé publique, elle, peut être copiée à volonté.

Il s'agit en fait d'un abus de langage. Les clés ne sont pas symétriques ni asymétriques, ce sont les procédés de chiffrement qui le sont.

C'est le plus facile à comprendre, c'est aussi la méthode de chiffrement la plus facile à réaliser et qui consomme le moins de ressources de calcul et de bande passante.

Les deux hôtes qui doivent échanger des données confidentielles (secrètes) disposent tous les deux d'une clé identique. L'émetteur chiffre les données avec, puis les envoie au récepteur. Ce dernier déchiffre avec la même clé pour récupérer des données lisibles.

Cette méthode assure la confidentialité des données, celui qui intercepterait la communication ne pourra pas lire les données échangées tant qu'il n'aura pas pu se procurer la clé. Il n'y a aucune authentification de faite sur l'émetteur comme sur le récepteur, sauf si deux personnes seulement disposent de la clé.

Le principal souci avec cette méthode, c'est qu'il faut s'échanger la clé et lors de cet échange, sans précautions particulières, n'importe quoi peut se produire.

Cette méthode permet de faire aussi bien l'authentification que la confidentialité des données. Il est évidemment possible de combiner les deux.

3-5-1. Principes de base▲

3-5-2. Authentification▲

Je réalise une empreinte avec un algorithme non réversible (MD5, SHA…). Cette empreinte ne permet pas de reconstruire le message original, mais elle représente « à coup sûr » un résumé de mon message original. Un simple bit modifié dans le message donnerait une empreinte complètement différente.

Je chiffre cette empreinte avec ma clé privée et l'envoie, avec le message en clair, au destinataire.

Mon message n'est pas confidentiel, il est envoyé en clair. Mais :

• l'empreinte réalisée est intimement attachée au contenu de mon message, si le message est intercepté et modifié, l'empreinte devra être recalculée,
• comme l'empreinte a été signée avec ma clé privée, je suis le seul à pouvoir le faire, donc toute modification ultérieure à l'envoi ne pourra pas être signée avec la bonne clé (aussi longtemps que ma clé privée restera secrète).

Lorsque le destinataire recevra le message signé :

• le destinataire recalcule l'empreinte du message reçu ;
• il déchiffre l'empreinte signée avec la clé publique de l'expéditeur ;
• il compare les deux empreintes. Si elles sont identiques, c'est que le message :
  • est bien conforme à l'envoi, puisque les empreintes sont identiques,
  • est bien envoyé par l'expéditeur propriétaire de la clé publique avec laquelle l'empreinte signée a été déchiffrée.

Voilà résolu le problème de la signature (authentifiée). Ce type de signature engage l'expéditeur. Il ne peut nier avoir envoyé cette information, puisqu'il l'a signée sans falsification possible, pour autant que l'on soit sûr de l'authenticité de la clé publique.

3-5-3. Confidentialité▲

3-5-4. Les deux▲

Vous avez compris le principe ? Alors, faire les deux devient simple :

• je réalise une empreinte de mon message et je la chiffre avec ma clé privée pour l'authentifier ;
• je chiffre le message lui-même avec la clé publique du destinataire pour le rendre confidentiel ;
• j'envoie le tout au destinataire.

Le destinataire déchiffrera le message avec sa clé privée, en calculera localement l'empreinte, puis déchiffrera l'empreinte envoyée avec ma clé publique :

• comme il est le seul à pouvoir déchiffrer avec sa clé privée, le message est bien confidentiel ;
• comme je suis le seul à pouvoir chiffrer l'empreinte avec ma clé privée, le message est bien authentique.

Bon. Ça roule, mais vous comprenez bien que l'opération est lourde :

• il faut chiffrer et déchiffrer deux fois au lieu d'une, comme on le ferait avec une clé symétrique ;
• le chiffrement/déchiffrement avec des clés différentes est une opération mathématique plus lourde, plus coûteuse en ressources CPU.

Rappelons que le principal problème du chiffrement symétrique est qu'il faut s'échanger l'unique clé à un moment donné et que, lors de cet échange, quelqu'un pourrait l'intercepter.

Ce problème va être résolu magistralement de la façon suivante.

Dans un échange d'informations (tunnel VPN par exemple), l'idéal, pour économiser les ressources CPU et augmenter le débit de l'échange, serait de trouver un moyen sûr d'échanger entre les partenaires une clé symétrique. Avec ce que nous savons, c'est relativement facile à réaliser.

Dans un premier temps, je fabrique une clé symétrique, à usage limité dans le temps, que nous appellerons une clé de session.

Je vais envoyer à mon interlocuteur cette « clé symétrique », que je vais authentifier et rendre confidentielle par les méthodes vues plus haut.

Et voilà le travail. Nous sommes deux à disposer de la même clé, transmise par une voie sécurisée.

La suite de l'échange pourra être chiffrée et déchiffrée avec cette clé de façon symétrique. Mais comme ça ne suffit pas, cette clé aura une durée de vie assez courte, quitte à devoir en échanger une nouvelle en cours de dialogue.

En effet, un intrus qui suivrait la discussion pourrait, au moyen d'outils faits exprès pour, finir par découvrir la clé symétrique, parce qu'il dispose d'un volume suffisant de données chiffrées, qu'il a eu le temps de trouver la clé grâce à la puissance de ses outils de cryptanalyse. Il faudra donc donner à la clé une durée de vie inférieure au temps nécessaire estimé pour la découverte de la clé.

Plus la clé sera « compliquée », plus ce temps sera long, mais plus les temps de chiffrement et de déchiffrement seront longs eux aussi. Tout est donc ici affaire de compromis.

Vous l'avez compris, cette magnifique mécanique ne fonctionnera qu'à une condition : le « concierge » (CA(3)) qui détient les clés publiques doit être digne de confiance, faute de quoi, n'importe quoi peut se produire…

Que pourrait-il arriver si une clé publique n'appartenait pas réellement à la personne indiquée ? Tout simplement une personne pourrait se faire passer pour une autre. Une fausse carte d'identité, en quelque sorte.

Tout repose donc sur la confiance que l'on peut mettre dans la personne qui détient les clés publiques.

Généralement, il s'agit d'un organisme de réputation sérieuse, à qui l'on confiera sa clé publique, et dont on détient la clé publique de façon sûre. La clé publique de l'organisme permettra de vérifier l'authenticité dudit organisme.

Il existe dans le monde plusieurs organismes (CA) de ce type. Leurs services, est-il nécessaire de le dire, ne sont pas gratuits, loin de là.

Lorsque je m'adresse à un tel organisme pour récupérer une clé publique, il me l'enverra avec un certificat. En gros, il s'agit pour ledit organisme de chiffrer la clé publique demandée, ainsi que quelques informations supplémentaires sur le propriétaire de cette clé, avec sa propre clé privée, pour authentifier son envoi. Il me reste à disposer de la clé publique du tiers de confiance, par un moyen sûr. Les certificats sont à la norme X.509.

Si je suis sûr de la clé publique du tiers et si j'ai confiance en lui, alors je pourrai mettre aussi ma confiance dans les clés publiques qu'il me distribuera.

Votre navigateur a installé, peut-être à votre insu, des certificats de divers organismes de certification (exemple avec Mozilla Firefox) :

Voici un résumé du contenu d'un certificat :

Et bien entendu, le certificat contient une clé publique :

Comme une clé s'use (le volume de données chiffrées avec devient trop important, ce qui risque d'augmenter significativement les chances de découverte de cette clé), il faudra prévoir une durée de vie à cette clé et donc au certificat.

Comme une clé peut se perdre ou être volée, il faudra aussi prévoir un système « d'opposition ». Une liste de révocation, qui permet de signaler les certificats non encore expirés, mais qui ne sont plus dignes de confiance pour une raison quelconque. La CA se doit donc de tenir à jour une liste de révocation, et, lorsqu'un utilisateur doit user d'un certificat qui est déjà en sa possession, il devrait commencer par vérifier si celui-ci n'a pas été révoqué entre temps.

Comme nous sommes dans un monde imparfait (d'ailleurs, si nous étions dans un monde parfait, les clés ne seraient d'aucune utilité), il peut se faire que l'usage de certains types de clés particulièrement « solides » soit réglementé. Il peut se faire qu'un exemplaire de la clé privée doive être mis sous séquestre, à disposition éventuelle des services de renseignements. Des organismes spécialisés dans cette mise sous séquestre de clés privées existent à cet effet.

Normalement, si deux interlocuteurs disposent chacun d'un certificat, mais chez des CA différentes, ils ne peuvent a priori se faire mutuellement confiance, sauf si par un procédé quelconque les deux CA affichent une confiance mutuelle. Entrer ici dans les détails nous mènerait vraiment trop loin, mais sachons tout de même que :

• les autorités de certification sont hiérarchisées, il y a des autorités racines et des autorités intermédiaires, ce qui aboutit à une structure arborescente. Si deux autorités intermédiaires sont certifiées par une même autorité hiérarchiquement supérieure, elles appartiennent au même arbre et donc la confiance est mutuelle, nous avons ici un arbre de confiance ;
• deux arbres différents peuvent à un niveau quelconque (mais supérieur à celui des partenaires impliqués), établir entre eux un lien de confiance mutuelle, ce qui donne naissance à des réseaux de confiance.

Une autre méthode consiste à utiliser un réseau de connaissances. J'ai, en principe, confiance dans mes amis et les amis de mes amis sont mes amis, donc, je peu faire confiance à une clé publique qui est contresignée par un ami dont je suis sûr. Ça peut aller loin, c'est le principe de l'homme qui a vu l'homme qui a vu l'homme qui a vu l'homme qui a vu Dieu.

C'est aussi le principe adopté en messagerie électronique par des procédés de signature comme GNUpg.

Les Public Key Infrastructures regroupent tout ce qui est nécessaire à la gestion des clés publiques et des certificats :

• récupération des demandes de certificats ;
• réalisation des certificats ;
• tenue de la liste de révocation,
• distribution des certificats aux demandeurs…

Lorsqu'une organisation désire mettre en place une telle infrastructure, sans avoir recours à des entreprises spécialisées, il lui est possible de le faire.

Bien entendu, les certificats produits n'auront de valeur qu'au sein de cette organisation. Il existe des projets Open Source qui proposent des outils de gestion d'infrastructure de clés publiques. Nous n'irons pas aussi loin dans cet exposé.

Le principe est donc assez simple, il faut au départ disposer de clés publiques appartenant à des gens dont on est sûr. Si ces gens dont on est sûr me certifient comme étant authentiques des clés de gens que je ne connais pas, ces clés publiques seront à leur tour réputées sûres.

Vous voyez la limite d'un tel système ? Non ? Alors, imaginez que dans la chaîne, il y ait une clé falsifiée qui passe pour authentique, à la suite d'une malversation quelconque. Alors, toutes les clés certifiées par cette clé falsifiée pourront être ou ne pas être authentiques…

Il est donc assez illusoire d'imaginer ce système comme parfaitement sûr. Fort heureusement, dans la plupart des cas, un seul administrateur certifiera les clés dont nous aurons besoin pour, par exemple, créer un tunnel sécurisé ou simplement une authentification entre deux nœuds d'un même réseau.

Dans la pile des protocoles réseau, il est courant d'utiliser le chiffrement :

• dans le noyau du système, au niveau IP, avec IPsec. Ainsi, tout ce qui passera sur le réseau sera automatiquement chiffré suivant les règles établies sans que les applications n'aient à s'en soucier ;
• dans l'espace utilisateur, au niveau des applications elles-mêmes, qui choisiront ou non de chiffrer, avec par exemple, SSL.  HTTPS en est une illustration, comme IMAPS, POPS ou encore SSH.

SSL, développé au départ par Netscape a été repris en open source sous le nom de TLS : Transport Layer Security. Protocole de sécurisation de la couche transport, défini par la RFC 2246. La version 1.0 de TLS est en fait SSL v3.

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.

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 ».

4-2-1. 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.

4-2-2. 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 toute manière, 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.

4-2-3. 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.

4-2-4. 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 empaquetterons le certificat et la clé privée dans des conteneurs différents.

4-2-4-1. 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).

4-2-4-2. 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.

4-2-4-3. Pour Betelgeuse▲

La procédure étant exactement la même, nous ne détaillerons pas non plus. Finalement, 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.

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