Présentation du logiciel auf-igc (IGC : Infrastructure de Gestion de Clé)

Objectif

Dans un premier temps : disposer d'un logiciel, sous forme de paquet Debian, permettant de gérer les clés, certificats et liste de révocation pour le Projet/RPVv2 de l'AUF. Plus tard, ce logiciel pourra aussi aider à émettre des certificats pour des serveurs https, imaps, pops, etc.

Grandes fonctionnalités :

• créer une autorité de certification (AC) racine, c'est-à-dire auto signée
• créer des AC intermédiaires, signées par l'AC racine
• générer des certificats pour des noeuds du RPV (un client et un serveur) et pour les nomades
• gérer la liste de révocation des certificats
• publier cette liste sur un serveur central spécifique
• télécharger depuis un serveur central spécifique l'ensemble des certificats et listes de révocation de l'IGC

Avancement

Une version est en cours de développement, disponible ici : http://tech.auf/~thomas/rpv2/ (accès RPV uniquement)

Actuellement le module de téléchargement est en cours de finition (19 septembre).

Description technique

Le paquet contient :

• un script shell auf-igc pour simplifier les appels à openssl, avec comme lointaine source d'inspiration easy-rsa fourni par OpenVPN

• un fichier /etc/auf-igc/openssl.cnf générique

• dans /usr/share/doc/auf-igc/ des fichiers d'exemple de configuration et cette doc (en format texte)

• ce qu'il faut pour configurer un serveur central (script CGI et exemple de configuration)

Pour le téléchargement de la CRL, le script travaille dans /var/lib/auf-igc/. Un CAPath est construit dans /var/lib/auf-igc/capath

Mode d'emploi

auf-igc tapé seul donne une petite aide en ligne.

Création d'un répertoire destiné à contenir une autorité de certification (AC)

On construit un répertoire qui contiendra l'AC (peu importe l'endroit, par exemple sur une clé USB...) :

  $ auf-igc prepare nom-de-l-AC

Pour utiliser l'AC, il faudra ensuite se placer dans le répertoire nom-de-l-AC et exécuter d'autres commandes auf-igc.

Initialisation de l'autorité de certification racine

Note: il n'existera qu'une seule CA racine, donc cette procédure ne sera pas répétée, mais je la laisse pour les curieux.

On prépare une AC comme indiqué ci-dessus, puis on génère une clé privée et un certificat auto-signé avec la commande racine du script auf-igc :

  $ auf-igc prepare repertoire-ac-racine
  $ cd repertoire-ac-racine
  $ auf-igc racine

Un mot de passe sera demandé pour protéger la clé privée (Enter PEM pass phrase). Note : oublier ou se faire pirater ce mot de passe serait une jolie catastrophe : c'est l'autorité racine depuis laquelle tout existe !

On obtient dans le répertoire de l'AC deux fichiers :

• ca-key.pem : la clé privée de l'autorité de certification. Cette clé est protégée par un mot de passe, mais même avec cette protection il ne faut absolument jamais la diffuser ou la montrer à qui que ce soit.

• ca-cert.pem : le certificat de l'autorité, auto-signé (c'est la racine). Ce certificat est en revanche public : il sera diffusé à tout équipement qui rentrera dans l'IGC.

Initialisation d'une autorité de certification régionale (AC intermédiaire)

Chaque région disposera de son autorité de certification propre. Ces AC seront intermédiaires, c'est-à-dire que le certificat de chaque autorité régionale aura été signé par l'autorité racine. Voici la procédure pour créer une autorité intermédiaire.

Etape 1 : sur la future AC régionale, créer la clé privée et la demande de certificat

Préparer un répertoire d'AC, puis produire une clé privée et une demande de certificat (region sera remplacé par le nom de la region, comme bap, bac ou boi)~:

  $ auf-igc prepare region
  $ cd region
  $ auf-igc intermediaire

Un mot de passe sera demandé pour protéger la clé privée (Enter PEM pass phrase).

On obtient deux fichiers :

• ca-key.pem : la clé privée de l'autorité de certification. Cette clé est protégée par un mot de passe, mais même avec cette protection il ne faut absolument jamais la diffuser ou la montrer à qui que ce soit.

• ca-region.csr : la requête de certificat, qu'il faut envoyer à l'autorité de certification de niveau supérieure (la racine) pour signature. Cette requête contient la clé publique de l'AC et quelques autres informations (code pays, région, ville, etc).

Etape 2 : l'AC régionale envoie la demande à l'AC racine

Le responsable de l'AC régionale doit envoyer le fichier ca-region.csr au responsable de l'AC racine ; par exemple par mail : il n'est pas nécessaire de crypter cette information qui est une clé publique.

Note : pour être sûr que la requête vient de voir, l'AC racine peut vous demander de signer cette demande. Cela peut se faire de plusieurs façons :

• soit vous avez déjà une technique pour envoyer votre message signé (par exemple avec opengpg) ;

• soit l'AC racine vous demandera de lui dicter, par téléphone ou tout autre moyen jugé fiable, la somme de contrôle MD5 de votre requête, obtenue avec : md5sum requests/ca-region.csr

Etape 3 : sur l'AC racine, on signe la requête

L'autorité racine doit placer le fichier ca-region.csr et le place dans le répertoire requests/. Puis elle le signe :

  $ cd racine
  $ cp /un/certain/repertoire/ca-region.csr ./requests/
  $ auf-igc signe ca-region

La procédure est alors déroulée ainsi :

1. Le mot de passe de l'AC racine est demandé afin d'accéder à sa clé privée (Enter pass phrase for ./ca-key.pem).

2. Ensuite les informationss sur le certificat seront affichées. Il faut les vérifier, notamment alors les dates de validité.

3. Puis openssl demande l'accord pour la signature du certificat (répondre "n" s'il y a un soucis) et enfin s'il faut bien ajouter ce certificat à la liste de ceux signés par l'AC (répondre "y").

Le certificat certs/ca-region.pem est alors produit. Il faut l'envoyer à l'autorité régionale qui avait fait la demande (par mail, tout simplement : un certificat est juste une clé publique signée, il est destiné à être diffusé).

Etape 4 : l'AC régionale installe son certificat désormais signé par l'AC racine

On installe le fichier ca-region.pem reçu depuis l'AC racine, en le renommant ca-cert.pem pour qu'il soit pris en compte comme certificat de l'AC locale par auf-igc.

Ca y est, vous avez une autorité de certification intermédiaire !

Utiliser son AC régionale pour créer des certificats

Pour un noeud du RPV

On doit créer deux certificats : un pour la partie serveur OpenVPN (qui reçoit des demandes de connexion) et un pour la partie cliente (qui demande des connexions). Pour cela, on utilise la commande "noeud" de auf-igc :

  $ auf-igc noeud implantation@10.X.Y.0

où implantation est le nom de l'implantation (par exemple dakar ou libreville) et 10.X.Y.0 le sous-réseau du RPV correspondant (X : code du pays, Y : réseau /20 dans ce pays).

La procédure se déroule selon les étapes suivantes :

1. une clé privée est créée pour le serveur (non crypté : aucun mot de passe n'est demandé) puis une requête de certificat est effectuer. Lors de la création de la requête, il faut préciser les données du certificat, à savoir le code ISO du pays de l'implantation, sa région, ville, etc. Le nom canonique doit avoir la forme server-implantation@10.X.Y.0-20

2. la même opération est exécutée pour la partie client, dont le nom canonique sera de la forme client-implantation@10.X.Y.0-20

3. ensuite les deux certificats seront créées en signant les deux demandes de certificat (server puis client). Il faudra donc fournir deux fois le mot de passe de l'AC régionale, et vérifier deux fois les informations du certificat avant de le signer (vérifier surtout les dates de validité).

A la fin de ces opérations, on obtient 4 fichiers :

• keys/server-implantation-key.pem et certs/server-implantation-cert.pem : la clé privée et le certificat pour le serveur OpenVPN de l'implantation cible

• keys/client-implantation-key.pem et certs/client-implantation-cert.pem : la clé privée et le certificat pour les clients OpenVPN de l'implantation cible

Il faut alors envoyer ces 4 fichiers au responsable technique de l'implantation ciblée, qui les installera à l'endroit prévu pour faire fonctionner le RPV.

TODO : donner une technique d'envoi sécurisée, les clés privées n'étant pas cryptées !

Pour un nomade

Pour un nomade, on crée un certificat dont le nom canonique sera prenom.nom@auf.org (l'adresse courriel de la personne). On précise la date de fin de validité (date de fin de contrat) :

  $ auf-igc nomade prenom.nom@auf.org AAMMJJ

Note : AAMMJJ = Année, Mois, Jour. L'année est sur deux chiffres et doit être strictement inférieure à 30.

La procédure se déroule alors selon les étapes suivantes :

1. création d'une clé privée, avec demande d'un mot de passe pour protéger la clé. Ce mot de passe devrait idéalement être choisi (saisi) par le nomade lui-même.

2. création d'une requête de certification : il faut alors fournir les renseignements comme le code ISO pays, la région, l'implantation et notamment le nom canonique qui devra être prenom.nom@auf.org

3. signature de la requête : il faut alors donner le mot de passe de l'AC régionale, puis valider la signature après avoir vérifier les paramètres affichés.

On a alors deux fichiers :

• keys/prenom.nom_auf.org-key.pem contient la clé privée, protégée par un mot de passe connu du seul nomade

• certs/prenom.nom_auf.org-cert.pem le certificat, émis (signé) par l'AC régionale

Ces deux fichiers devront être installés sur le poste client du nomade afin qu'il accès au RPV.

Liste des certificats

Pour obtenir des détails sur les certificats contenus dans certs/ :

  $ auf-igc liste

Cela affiche notamment les dates de validité et le nom canonique de chaque certificat.

Révocation d'un certificat : gestion de la CRL

A tout instant une autorité de certification peut révoquer un certificat (principalement en cas de compromission d'une clé privée). Pour cela, plusieurs techniques existent. Au niveau de l'AUF (et du ProjetRPVv2) nous avons décidé de créer et diffuser des listes de certificats révoqués (CRL) pour chaque AC. Voici comment gérer cette liste.

Révoquer un certificat

  $ auf-igc revoque nom-du-certificat

Demande la révocation du certificat contenu dans certs/nom-du-certificat-cert.pem. Le mot de passe de la clé privée de l'AC sera demandé (Enter pass phrase). Le certificat sera alors listé comme révoqué dans la liste index.txt. Cependant, pour diffuser cette information, il faut générer puis publier une liste des certificats révoqués (CRL).

Important : pour révoquer un noeud RPV, il faut révoquer les deux certificats, serveur et client.

Générer la liste des certificat révoqués (CRL)

  $ auf-igc crl

Le mot de passe de la clé privée sera demandé, car la CRL doit être signée par l'AC. Il en résulte la création d'un fichier crl.pem, qui doit être envoyé sur les sites centraux de CRL de l'IGC AUF. C'est l'objet de l'étape suivante.

Publier la liste des certificat révoqués (CRL)

  $ auf-igc publie-crl

La CRL est alors envoyée à un ou plusieurs serveur centraux. Pour chaque serveur central le mot de passe de la clé privée sera demandé, car la connexion est authentifiée et cryptée en utilisant la clé privée et le certificat de l'AC.

---

A faire - Pense-bête

• IMPORTANT : faire un auf-igc qui construit /var/lib/auf-igc/capath/ !

• programmer un "auf-igc verifie" qui checke tout ce qu'il faut (cela impose ce qui précère : la présence du capath)
• programmer un "auf-igc motdepasse" pour changer le mot de passe de l'AC ou d'une clé privée
• comment indiquer des dates (début/fin) lors de la création d'un certif noeud ?

• à la fin de "nomade" ou "noeud", faire un .zip ou .tar.gz des clés et certif émis (zip pour les nomades windows, ou bien un PKCS-truc qui peut tout contenir => voir ce que peut faire openvpn-win32 de ce coté)

• en plus de "nomade" et "noeud", ajouter une commande "serveur nom.du.serveur" pour créer un certificat serveur pour nom.du.serveur (utilisations pour serveurs web, imap, pop, smtp, etc)
• downloader des certificat d'AC, d'accord, mais comment vérifier un minimum qu'ils sont ok ? idée : mettre le fingerprint dans un champ TXT de la DNS ? (exemple :

  ca-racine-sha1.rpv.auf.org IN TXT "83:08:1F:10:61:52:FC:BC:37:CE:C9:F8:7D:CE:B5:6B:24:8B:1B:68"
  ca-racine-md5.rpv.auf.org IN TXT "01:11:40:43:B4:5A:2F:9E:F2:1A:D5:6B:E8:76:58:31"

• Ca me parait pas mal... ou bien l'inverse : trouver le TXT associé à une somme de controle ? Ce TXT doit être le DN de l'AC associée :

  sha1-83-08-1F-10-61-52-FC-BC-37-CE-C9-F8-7D-CE-B5-6B-24-8B-1B-68 IN TXT "/C=CA/ST=Quebec/L=Montreal/O=AUF/OU=DRI/CN=AUF-AC-Racine/emailAddress=rpv@auf.org"
  md5-01-11-40-43-B4-5A-2F-9E-F2-1A-D5-6B-E8-76-58-31 IN TXT "/C=CA/ST=Quebec/L=Montreal/O=AUF/OU=DRI/CN=AUF-AC-Racine/emailAddress=rpv@auf.org"

• C'est mieux non ?...