## page was renamed from Projet/PKI/CréationDesAutorités = Préliminaires = Dans tout ce qui suit `openssl-auf.cnf` est le fichier disponible [[http://git.auf.org/?p=pki;a=blob;f=ca-certificates-auf/openssl-auf.cnf;hb=HEAD|sur le dépôt git]] associé au projet PKI. Ce fichier sera inclus dans le paquet `ca-certificates-auf`, à venir. Pour éviter d'avoir à préciser systématiquement `-config openssl-auf.cnf` lors de l'appel à openssl, on peut fixer la variable d'environnement `OPENSSL_CONF`. On peut par exemple le faire dans le script de connexion de l'utilisateur qui devra gérer l'autorité de certification : {{{ # (... à ajouter à la fin de ~∕.bashrc ...) # pour éviter de devoir systématiquement préciser -config ... export OPENSSL_CONF=/etc/ssl/openssl-auf.cnf }}} = Création d'une AC racine = 1. Préparation {{{ racine$ mkdir racine; cd racine; mkdir certs newcerts ; echo 01 > serial ; echo 01 > crlnumber ; touch index.txt .rand }}} 1. Création d'une clef privée 2048 bits (cryptée par un mot de passe) et d'une requête de certificat : {{{ racine$ openssl req -config openssl-auf.cnf -newkey rsa:2048 -out request-ca-racine.pem Generating RSA private key, 2048 bit long modulus ......................+++ e is 65537 (0x10001) Enter pass phrase for ca-key.pem: Verifying - Enter pass phrase for ca-key.pem: (...) Code ISO du pays (2 lettres) [CA]: Province ou region (nom complet) [Quebec]: Ville (nom complet) [Montreal]: Organisation [AUF]: Unite (implantation, service, programme, ...) [DRI]: Nom canonique (TOUJOURS TRES IMPORTANT) [AUF-AC-RACINE]: Adresse electronique (email) [rpv@auf.org]: }}} 1. Auto-signature du certificat (on est sur la racine) avec les extensions spécifiques (ca_racine): {{{ racine$ openssl ca -config openssl-auf.cnf -selfsign -extensions ca_racine -in request-ca-racine.pem -out ca-cert.pem Using configuration from openssl-auf.cnf Enter pass phrase for ca-key.pem: Check that the request matches the signature Signature ok Certificate Details: (...) Certificate is to be certified until Mar 5 10:20:49 2018 GMT (3650 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated }}} 1. Un peu de protection contre les mauvaise manipulations : {{{ $ chmod 0400 ca-key.pem $ chmod 0444 ca-cert.pem }}} 1. Initialisation de la CRL (sera forcément vite) : {{{ $ openssl ca -config openssl-auf.cnf -gencrl -out ca-crl.pem }}} Note : pour ceux qui connaissent openssl, on pourrait faire le tout en une seule étape, sans passer par une requête de certificat. Mais en utilisant la technique requête + auto-signature, le certificat auto-signé se retrouve dans la ligne des certificats signés par l'AC (fichier `index.txt`). Je trouve ça plus cohérent. '''Pour résumer :''' {{{ $ export OPENSSL_CONF=/etc/ssl/openssl-auf.cnf $ mkdir racine; cd racine; mkdir certs newcerts ; echo 01 > serial ; echo 01 > crlnumber ; touch index.txt .rand $ openssl req -newkey rsa:2048 -out request-ca-racine.pem $ openssl ca -selfsign -extensions ca_racine -in request-ca-racine.pem -out ca-cert.pem $ chmod 0400 ca-key.pem ; chmod 0444 ca-cert.pem $ openssl ca -gencrl -out ca-crl.pem }}} == Vérification des résultats == Examen du certificat produit (vérification des dates et des extensions) : {{{ racine$ openssl x509 -text -in ca-cert.pem -noout <-- liste de toutes les données du certificat, notamment dates et extensions racine$ openssl x509 -purpose -in ca-cert.pem -noout <-- liste des utilisations possibles du certificat racine$ openssl crl -in ac-crl.pem -text <-- contenu de la CRL }}} = Création d'une AC régionale = Dans ce qui suit, remplacer `regionX` par le nom abrégé de la région. 1. Préparation {{{ region$ mkdir regionX; cd regionX; mkdir certs newcerts ; echo 01 > serial ; echo 01 > crlnumber ; touch index.txt .rand }}} 1. Création de la clé (cryptée par un mot de passe) et établissement de la demande de certificat : {{{ region$ openssl req -config openssl-auf.cnf -newkey rsa:2048 -out request-ca-region.pem Generating RSA private key, 2048 bit long modulus ......................+++ e is 65537 (0x10001) Enter pass phrase for ca-key.pem: Verifying - Enter pass phrase for ca-key.pem: (... exemple pour le BAO ...) Code ISO du pays (2 lettres) [CA]:SN Province ou region (nom complet) [Quebec]:. Ville (nom complet) [Montreal]:Dakar Organisation [AUF]: Unite (implantation, service, programme, ...) [DRI]: Nom canonique (TOUJOURS TRES IMPORTANT) [AUF-AC-RACINE]:AUF-AC-BAO Adresse electronique (email) [rpv@auf.org]: }}} 1. Le fichier `request-ca-regionX.pem` est la demande : il doit être envoyé à l'autorité de certification racine 1. '''Sur l'AC racine''' : la demande est signée et devient un certificat `certs/ca-regionX.pem` qui possède les extensions x509 requises pour une autorité de certification : {{{ racine$ openssl ca -config openssl-auf.cnf -in request-ca-regionX.pem -extensions ca_region -out certs/ca-regionX.pem }}} 1. '''Retour à l'AC régionale''' : le fichier `certs/ca-regionX.pem` est renvoyé à l'autorité régionale, qui le renomme `ca-cert.pem` : c'est le certificat, placé à côté de `ca-key.pem` qui est la clé privée correspondante. 1. Un peu de protection contre les mauvaise manipulations : {{{ $ chmod 0400 ca-key.pem $ chmod 0444 ca-cert.pem }}} 1. Initialisation de la CRL (sera forcément vite). Noter qu'on indique à `openssl` la variable d'environnement `REGION` qui doit contenir le nom de la région (typiquement `bao` ou `beom`, en minuscules), cette variable est utilisée dans des extensions ajoutées à la CRL : {{{ $ REGION=xxxx openssl ca -config openssl-auf.cnf -gencrl -out ca-crl.pem }}} = Utilisation de git pour transfert vers igc.auf.org = Le certificat des autorités mais surtout les '''liste de révocation de certificats''' (CRL) doivent être envoyés sur le serveur central `igc.auf.org` qui se chargera de les proposer au public de divers façon : mise en ligne sur http://igc.auf.org/, mise à jour du paquet `ca-certificates-auf`, accès LDAP, serveur OCSP, etc. Nous avons décidé d'utiliser le système [[Git]] pour cela, qui va transférer les données et leur historique via un canal crypté ssh. Pour rajouter une couche de sécurisation, ceci ne sera possible que dans le réseau privé virtuel de l'AUF. '''Chaque responsable d'une autorité de certification de l'AUF dispose d'un accès sur `igc.auf` lui permettant d'envoyer les modifications effectuées au niveau de son autorité.''' Cet accès se fait par ''ssh'' avec authentification par clé, l'accès à ssh n'étant possible que depuis le réseau privé virtuel de l'AUF. == Préparation de l'hébergement git sur igc.auf.org == Chaque répertoire contenant une AC doit donc devenir un dépôt git. Voici la procédure à suivre : 1. On initialise `git` sur la racine de l'arborescence de l'AC (répertoire où l'on trouve `ca-cert.pem`, entre autres) : {{{ $ cd AC $ git init-db <-- ou "git init" si git est en version 1.5 (Ubuntu Gutsy ou Debian Lenny) }}} 1. On configure git pour qu'il n'envoie '''jamais''' ni la clé privée ni le fichier d'aléa : {{{ $ echo "*-key.*" >> .git/info/excludes $ echo ".rand" >> .git/info/excludes }}} 1. On envoie tous les fichiers dans le dépôt (sauf la clé privée, exclue ci-dessus) : {{{ $ git add $ git commit -a -m "mise sous git de l'AC truc" }}} 1. On prépare une copie du dépôt destinée à être stockée sur le serveur igc.auf.org : {{{ $ cd .. $ git clone --bare AC AC.git }}} 1. On envoie cette copie sur le serveur igc.auf.org (en rsync+ssh, via le RPV, en utilisant le compte `user` fourni par un des responsables technique de igc.auf.org) : {{{ $ rsync -av AC.git user@igc.auf: <-- "user" est fourni par un responsable technique de igc.auf.org }}} 1. '''Sur igc.auf''', le dépôt sera éventuellement renommé et transformé en dépôt git de type "dumb", classiquement : {{{ user@igc.auf$ mv AC.git git user@igc.auf$ cd git user@igc.auf$ echo "IGC AUF - autorite truc" > description user@igc.auf$ touch git-daemon-export-ok user@igc.auf$ git --bare update-server-info user@igc.auf$ chmod a+x hooks/post-update }}} 1. '''Sur la machine qui gère l'AC''', on peut alors configurer le dépôt git local pour en simplifier l'utilisation : {{{ $ cd AC $ mkdir .git/remotes $ echo "URL: ssh://user@igc.auf/~/git" > .git/remotes/origin <-- un "git push" enverra à cette URL directement }}} 1. Petit test : {{{ $ git push Everything up-to-date }}} == Utilisation du dépôt git == Lors de toute modification de la CRL, il faut absolument envoyer la nouvelle version vers le serveur central. Pour cela, on lance un ''commit'' git : {{{ $ (... revocation puis construction de la nouvelle CRL, aux formats PEM et DER ...) $ git commit ca-crl.pem -m "mise à jour CRL: revocation de tel certif pour tel mobile" $ git push }}} On peut aussi (fortement recommandé) faire un ''commit'' après n'importe quelle utilisation de l'AC afin d'enregistrer l'historique des certificats crées, notamment des fichiers `serial` et `index.txt`. La manipulation est identique : {{{ $ git commit -a -m "raison du commit" $ git push }}} == Ce qui se passe une fois le push effectué == Une fois que les données ont été envoyées sur igc.auf.org, c'est ce dernier qui va faire le travail. Un ''cron'' fonctionne toutes les 5 minutes qui regarde si une nouvelle CRL a été publiée. Si c'est le cas, elle est automatiquement publiée sur le web http://igc.auf.org/, dans le ldap, via OCSP et une nouvelle version du paquet ca-certificates-auf est construite et envoyée sur le [[DépôtAPT]] de l'AUF. Résultat : la nouvelle CRL est en ligne au maximum 10 minutes après avoir été envoyée via ''git''. Le processus est décrit en détail sur la page ../DiffusionDesInformations.