Vous êtes ici: L'internet rapide et permanent » Notions de cryptographie » Mise en œuvre avec TinyCA

Les chapitres Mise en œuvre avec TinyCA Table des matières

Nous aurons l'occasion de mettre en pratique diverses méthodes de chiffrement dans le tunnel Mise en œuvre avec TinyCA
La fibre optique OpenVPN et aussi dans la sécurisation d'un réseau WI-FI, sans oublier également SMTP, POP3 et Rappels
Bande passante IMAP sécurisés. Utilisation de TinyCA
Le codage des caractères Création de la CA
Certificat du serveur
TCP/IP(v4) Nous allons plutôt ici nous intéresser à la réalisation d'une mini « CA » à l'aide d'OpenSSL. Présent Certificat du client
IP v6 sur toutes les distributions GNU/Linux, cet outil se présente sous forme de commandes en ligne dont Export des clés et
IP et le Routage l'ergonomie n'a d'égale que la complexité de l'outil. certificats
La CA d'abord
Le routage, compléments Pour Coquelicot
Le routage sélectif Plus avenant, TinyCA propose une interface graphique pour manipuler les diverses commandes Pour Betelgeuse
Partage de connexion d'OpenSSL de façon plus compréhensive. Nous allons donc réaliser au moyen de TinyCA :
TCP/IP & sécurité
NetFilter et IPtables une autorité de certification « maison », avec son propre certificat ;
PPPoE un certificat pour un serveur, contre-signé par notre autorité « maison » ;
DNS un certificat pour un client, également contre-signé par notre autorité « maison ».
DHCP 1)
SMTP Notons que TinyCA n'est pas une PKI . Il ne fait rien de plus que ce que sait faire OpenSSL.
POP3
IMAP
SMTP/IMAP en pratique Rappels
FTP Rappelons tout de même brièvement ce qu'est un certificat.
HTTP
SNMP L'objectif est de pouvoir distribuer une clé de chiffrement publique, avec tout ce qu'il faut comme informations pour :
Squid et SquidGuard
identifier clairement le propriétaire de cette clé publique ;
Notions de cryptographie
obtenir « l'assurance » de l'authenticité de ce certificat.
Position du problème
Les clés du chiffrement Le second point est obtenu par la signature dudit certificat par une autorité « de confiance », elle même pouvant être certifiée par une
Mise en œuvre avec TinyCA autorité supérieure, etc. Dans un tel cas, le certificat doit contenir les informations nécessaires pour pouvoir remonter et obtenir si
Virtual Private Network besoin est les certificats des autorités successives, jusqu'à l'autorité « ultime ».
Le Wi-Fi
Sécuriser son réseau
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.
Kerberos
NTP (l'art d'être à l'heure) Parallèlement, une entreprise peut très bien créer sa propre autorité « racine » et authentifier des certificats qu'elle émet pour les
Astuces diverses besoins de son entreprise (ou même de ses clients). Nous allons opérer dans ce cadre.
A notre regretté internet
Pas de « Facebook » pour moi
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.

Dernière modification:: le 30/06/2018 à 17:47

Administrer S'identifier Rechercher Rechercher Afficher le texte source

Cette création est mise à disposition sous un contrat Creative Commons.