polux     Julien Thomas - TELECOM Bretagne frenchenglish

Introduction à SSL et aux certifications

SSL et chaînes de certification

SSL (Secure Sockets Layers) est un procédé de sécurisation. Le standard SSL a été mis au point par Netscape, en collaboration avec Mastercard, Bank of America, MCI et Silicon Graphics. Il repose sur un procédé de cryptographie par clef publique. Son principe consiste à établir un canal de communication chiffré entre deux machines après une étape d'authentification. Le système SSL n'assure pas le chiffrement par lui-même, étant donné qu'il est indépendant du protocole utilisé. En effet, SSL se comporte comme une couche supplémentaire abstraite située entre la couche application et la couche transport. Le mécanisme de chiffrement est négocié entre les deux entités.

Les certificats ont pour but d'assurer l'authentification des entités. Il s'agit de clés RSA publiques émises par les entités. Ces certificats sont ensuite vérifiées lors de l'utilisation des clés privées en tant que preuves (technique de signature). Les chaînes de certifications sont utilisées pour simplifier (et aussi assurer) l'authentification des certificats des entités. Ainsi, chaque client désirant utiliser un service a besoin de simplement connaître la liste des certificats root, ceux étant internationalement reconnus. A partir de ces certificats, il est possible de valider l'authenticité d'un serveur si son certificat est signé par l'un des certificats racines ou s'il existe une chaîne de certification menant à un certificat racine. Il n'est pas donc nécessaire de connaître à priori le certificat, ce qui limite les attaques par usurpations d'identités (phissing).

Création du certificat racine (Root Certificate)

Dans notre cas, nous avons utilisé un certificat de base permettant de signer l'ensemble des autres certificats de la maquette. Si l'on avait voulu avoir un service accessible en ligne, il aurait alors été nécessaire et suffisant de signer ce certificat de base par une entité reconnue (certificat racine ou transitivement signée par un certificat racine).

L'ensemble des opérations liées aux certificats a été réalisé en utilisant le projet openSSL, gratuit et largement documenté. L'ensemble des opérations ont été effectuées sur la machine mv4, afin de limiter la propagation des clés SSL (et de centraliser leur gestion).

La première étape consiste à créer le certificat de base avec la commande CA.pl -newcert :

cd /home/
/etc/ssl/misc/CA.pl -newcert
iamthecaroot
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:France
Locality Name (eg, city) []:Rennes
Organization Name (eg, company) [Internet Widgits Pty Ltd]:POLUX
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:POLUX Staff
Email Address []:admin@polux.org

Après avoir créé le ceritifcat, il faut initialiser (vérifier) la librairie openSSL

cd /etc/ssl/
cp /home/newkey.pem private/cakey.pem
cp /home/newcert.pem cacert.pem
echo > /etc/ssl/index.txt
echo 01 > /etc/ssl/serial

La troisième étape a pour but d'ajouter le certificat polux dans la liste des certificats reconnus (dossier certs). Cette étape doit être réalisée sur les différentes machines, afin de pouvoir utiliser les chiffrements SSL sur les différents serveurs.<:p>

cd /etc/ssl/certs
cp  ./
ln -s polux.pem `openssl x509 -hash -noout -in polux.pem`.0

Il est à noter que différentes informations peuvent être importante lors de la génération d'un certificat. Premièrement la valeur Country Name est restrictive au sens où tous les certificats fils devront obligatoirement avoir le même cette même valeur. Deuxièmement, le Common Name (CN) permet d'effectuer un contrôle d'identité important. Dans le cas du certificat racine, cela n'est pas important étant donné que le certificat n'a pas pour vocation à être utilisé directement. Cependant, pour les certificats fils, c'est très important, afin d'éviter l'apparition d'alertes SSL, voir le rejet des certificats. Le CN doit en effet correspondre à l'url de connexion. Par exemple, pour apache, il faudra spécifier CN: webmail.polux.org.

Certificats utilisés sur la maquette

Dans le cadre du projet POLUX, le schéma de certification suivant a été utilisé.

certificats



«Design-by-assumption works as long as assumptions hold. Assumptions are shortcuts to useful efficiencies, provided they are not violated. »
David S. Isenberg

«If the kernel is not evaluated to an MLS-capable protection profile, MLS features cannot be trusted regardless of how impressive the demonstration looks.»
J. Davidson