Préliminaires

Dans tout ce qui suit openssl-auf.cnf est le fichier disponible 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

2. 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]:

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

4. Un peu de protection contre les mauvaise manipulations :

   $ chmod 0400 ca-key.pem
   $ chmod 0444 ca-cert.pem

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

2. 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]:

3. Le fichier request-ca-regionX.pem est la demande : il doit être envoyé à l'autorité de certification racine

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

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

6. Un peu de protection contre les mauvaise manipulations :

   $ chmod 0400 ca-key.pem
   $ chmod 0444 ca-cert.pem

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

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

3. 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"

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

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

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

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

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