#redirect Projet/PKI 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`). 1. Ensuite les informationss sur le certificat seront affichées. Il faut les vérifier, notamment alors les '''dates de validité'''. 1. 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` 1. 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` 1. 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. 1. 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` 1. 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 ?...