Distribution EOLE

h1. Gestion certificats

Ce mémo fait le point sur la problèmatique des certificats sur les modules EOLE.

h2. Usage des certificats sur les modules EOLE

Sur les modules EOLE, les certificats sont utilisés pour identifier et authentifier différents services :

* ead ;

* eole-sso ;

* sites et applications web desservies par apache ;

* transmission des journaux d'application.

h2. Deux modes de fonctionnement

Deux modes d'utilisation des certificats sont proposés par les modules EOLE.

Un mode intégré à une pki reconnue (dont les certificats racines sont intégrés aux navigateurs) et un mode indépendant reposant sur un certificat racine local ou non reconnu.

Les modes peuvent être utilisés concomitamment. Par exemple, on peut avoir un certificat intégré à une pki pour les sites desservis par apache et un certificat signé "localement" pour la transmission des journaux d'application.

h3. Mode indépendant

C'est le mode par défaut, mis en place à l'instanciation du serveur.

Ce mode permet de fonctionner en attendant la signature de la clé publique du module par une pki, -celle de Toulouse dans le cas des établissements scolaires du second degré par exemple-.

Les certificats applicatifs permettent les mêmes usages qu'en mode intégré.

Par contre, en l'absence d'une pki, il n'y a pas de gestion des listes de révocations.

Les certificats applicatifs et certificats racines doivent être acceptés manuellement.

h3. Mode intégré

C'est le mode conseillé pour les applications web en particulier, les applications faisant intervenir des logiciels clients en dehors des serveurs EOLE en général.

Actuellement, pour l'Éducation nationale, l'autorité de référence est TERENA. La chaîne de certification a deux niveaux.

h4. Configurations des applications

La configuration des applications se résume souvent à présenter la chaîne de certification à l'application dans un ou plusieurs fichiers.

La concaténation des certificats est la seule opération à connaître et peut être opérée, à la main, grâce à la commande openssl.

Soit une chaîne de certification définie par un certificat serveur.crt établi à l'aide d'un certificat cert_intermediaire.crt, lui-même établi à l'aide du certificat autosigné appartenant à une autorité reconnue cert_racine.crt. La concaténation de la chaîne complète prendrait la forme suivante :

<pre>

openssl x509 -in serveur.crt > chaine.crt

openssl x509 -in cert_intermediaire.crt >> chaine.crt

openssl x509 -in cert_racine.crt >> chaine.crt

</pre>

L'ordre de concaténation est important.

h5. Apache

Apache dispose de deux variables : 

* une pour le certificat du serveur, le certificat délivré par TERENA non concaténé (variable apache_cert) ;

* une pour le reste de la chaîne (pas de variable au niveau creole car cette chaîne est calculée automatiquement pour peu que le fichier indiqué pour la variable précédente ne contienne pas la chaîne).

Le reste de la chaîne ne devrait pas inclure le certificat racine autosigné, normalement dans le magasin du navigateur web.

h5. Nginx

Nginx dispose d'une variable :

* certificat du serveur concaténé avec le reste de la chaîne.

h5. Eole-sso

Eole-sso dispose de 2 variables :

* certificat du serveur concaténé avec les certificats intermédiaires (variable eolesso_cert /etc/ssl/certs/eole.crt par défaut);

* le certificat racine autosigné (variable eolesso_ca_location).

h2. Extensions des certificats

h3. Certificat racine

h3. Certificats applicatifs