Téléchargez la version PDF : Certificats TLS-SSL.pdf

Dernière mise à jour :samedi 19 octobre 2013

Objectif

Ce document a pour objectif de présenter une manière "simple" de mettre en oeuvre le protocole TLS/SSL pour un serveur LDAP.

TLS 1.1 = Transport Layer Security. RFC 4346, avril 2006.

✓

SSL 3.0 = Secure Sockets Layer. Netscape Corporation. 1996. Internet Draft.

✓

TLS 1.1 est souvent considéré comme étant SSL 3.0, mais ce n'est pas exactement interchangeable.

✓

Tout comme Michel Cardie, tout a commencé un jour où nous avons, enfin, voulu mettre en œuvre une connexion sécurisée, c'est-à-dire utilisant TLS/SSL, pour service de messagerie sous «Postfix» avec une authentification LDAP et c’était l’occasion ou jamais. Ce n'est pas simple. Surtout quand on débute. Et il est vrai qu’on n’en fini pas de débuteravec cette affaire!!! N'hésitez pas à me dire si il y a une grosse erreur, ça fait toujours avancer.

Cette documentation est directement inspirée de celle de Michel Cardie. À tout seigneur, tout honneur, c’est lui donc qu’il faut remercier, surtout pour l’approche très didactique, partant de l’exemple, dont il a sut faire preuve. C’est tellement rare qu’il faut absolument l’en remercier.

Tout ce système est basé sur OpenSSL1.

Quand on croit avoir compris…

Un client LDAP (Cli) souhaite établir une connexion TLS/SSL avec un serveur LDAP (Srv). Ici, seul le serveur (Srv) doit prouver son identité. Le client (Cli) n'est donc pas contraint de fournir un certificat au serveur. Ce cas est prodigieusement intéressant car de nombreux clients simples sont incapables de fournir un quelconque certificat.

Le client (Cli) se connecte au serveur serveur (Srv).

✓

Leserveur (Srv) communique au client (Cli) un certificat (Crt).

✓

Le client (Cli) teste la validité du certificat (Crt).

✓

Une fois établie l'identité du serveur (Srv), le client (Cli) peut généralement poursuivre.

Là où ce n'est pas évident, c'est qu'il faut:

1.créer plusieurs certificats,

✓

les gérer (c'est-à-dire les placer correctement aux bons endroits avec de "bons" noms),

2.

les tester (d'abord à l'aide des outils ayant servis à les créer, puis, et c'est le plus important, avec les clients LDAP).

Lorsque le serveur (Srv) envoie généralement un certificat dit «auto-signé», c’est à dire certifié par lui-même, ce n’est pas très sûr. D’ailleurs, en général, les applications recevant un tel certificat ouvrent une fenêtre signalant le problème et demandent une confirmation d’exception2 avant de poursuivre. Ce n’est pas très «professionnel» et perturbe souvent les utilisateurs. En outre, ça invalide, dans une certaine mesure, l’utilité de cette procédure d'authentification car les utilisateurs prennent l’habitude de confirmer les exceptions sans même lire les données affichées et peuvent donc être trompés facilement.

Le moyen de ne pas se trouver dans cette situation, c’est que le serveur fournisse un certificat signé par une «autorité» déjà validée et connue. C’est en fait un autre certificat, identique à celui fourni pour l’application mais pas dédié à un usage particulier autre que celui de certifier un certificat. C’est ce qu’on appelle un «Certificat d’autorité».

Dans le cas des connexions sécurisées des serveurs privés (banques, assurances, FAI, …), ces entreprises s’appuient sur des certificats d’autorité connus et payant (Camerfirma SA, America online, AOL Time Warmer Inc., VeriSing Inc., Thawte Consulting cc, …). Outre le coût d’un tel système, se pose le problème que ce genre de certification donne à ces entreprises un pouvoir : celui d’accepter ou non de vous servir. Heureusement, le nombre d’organismes atténue ce danger, il n’en reste pas moins qu’étant très majoritairement des USA, des intérêts croisés existent. Heureusement, il existe également un projet «Open Source», donc ouvert, international et libre de contraintes tant financières que politique : le «CA Cert».

Mais, en fin de compte, certificat d’autorité ou non, il faudrait bien, à un moment ou à un autre, que vous ayez accepté au moins les certificats d’autorités. Que vous les ayez en quelque sorte, signés. C’est là que se trouve «l’entourloupe». En fait, tous vos logiciels considèrent que les certificats d’autorité privés ont bons. En fait, on considère, sans vous le demander, que vous les avez «signés». Ce qui est absolument inacceptable. Effectivement, en validant la pointe de la pyramide, on valide, de fait, tous les «fils» de ces certificats. Ça répond à une certaine logique mais comment se fait-il alors que le seul organisme véritablement libre et indépendant (CA Cert) ne le soit pas ?

Ici, nous avons choisi que créer nos propres certificats d’autorité, correspondant à notre organisme, qui servirons donc à signer tous les certificats nécessaires à nos connexions sécurisées. Il suffit de nous faire connaître, de nous faire accepter par nos utilisateurs pour qu’ils signalent à leurs logiciels que notre certificat d’autorité est valide. C’est, en fait, bien plus moral que ce que fait Verisign en payant pour avoir son certificat d’autorité inclus automatiquement à toutes les applications. Lorsque nous aurons tout bien mis en place nous nous appuierons sur le certificat d’autorité du CA Cert.

Préparation de l’organisation des certificats.

On utilise OpenSSL. C’est en ligne de commande, ça a plein d’options tellement ça fait de chose. Objectivement, on lit la documentation uniquement quand on en a absolument besoin. On se fait sa tambouille en fonction de ce dont on a besoin. On retient bien plus l’endroit où on a noté certaines options et la syntaxe lors d’un usage que de mémoriser la chose. En un mot, cette documentation, c’est aussi ma tambouille personnelle.

On va créer ici trois certificats. On aurait pu en faire seulement deux, c'est certain, mais c’est histoire de bien montrer comment ça marche.

En fait, il faut voir cette histoire de certificats comme un arbre. La feuille est la seule à avoir une fonction déterminée : la respiration. C’est la dernière extrémité, tous les autres objets sont rattachés à un autre objet mais servent également d’attache pour un suivant. En gros, si on oublie les racines, le «certificat d’autorité racine», c’est le tronc. Les branches, ce sont des «certificats d’autorité spécialisés» pour un groupe. Le «certificat» final, il correspond à une et une seule entité, c’est la feuille. On peut parfaitement imaginer n’avoir qu’un tronc («certificat d’autorité racine») pour une multitudes de feuilles («certificats» simples).

3.

Ensuite, il va falloir organiser les différents certificats de façon à ce que les clients et serveurs puissent les trouver et les tester. On utilise l'organisation proposée dans le fichier de configuration de openssl. Autrement dit, dans le fichier openssl.conf.

La variable d'environnement OPENSSL_CNF permet de spécifier quel fichier de configuration utiliser. Ceci peut être particulièrement utile dans le cas de l'existence de multiples versions de ce type de fichier.

On a donc l'organisation suivante:

$dir = le répertoire de base (ex: /usr/local/ssl ou /usr/share/ssl)

✓

$dir/certs = le répertoire où sont conservés les certificats (plus exactement, des noms de la forme hash.0)

✓

$dir/crl = le répertoire où sont conservées les listes de révocation.

✓

$dir/newcerts = le répertoire où sont stockés les certificats nouvellement créés.

✓

$dir/private = le répertoire où sont stockées les clés privées

✓

$dir/index.txt = le fichier d'index de la base de données

✓

$dir/serial = le fichier qui contient le prochain numéro de série pour tout nouveau certificat qui sera créé.

Le certificat racine est placé directement dans $dir.

La clé privée du certificat racine est dans $dir/private.

✓

Bien qu'il soit théoriquement possible de créer et gérer des certificats en utilisant le fichier de configuration principal de openssl (soit, openssl.cnf), il peut être beaucoup plus judicieux d'utiliser divers fichiers de configuration pour les différents cas de figures que l'on va rencontrer. Voici une liste de différents fichiers de configuration. Je ne les ai pas inventés; je les ai simplement extraits du livre «LDAP system administration, Gerald Carter, O'Reilly®».

root-ca-cert.cnf pour la requête et l'auto-signature du certificat racine Root CA

✓

req-subca-cert.cnf pour générer la requête du certificat LDAP CA

✓

req-server-cert.cnf pour une requête de certificat concernant un serveur

✓

req-user-cert.cnf pour une requête de certificat concernant un client

✓

ca-subca-cert.cnf pour signer le certificat LDAP CA par le certificat racine Root CA

✓

ca-server.cert.cnf pour signer le certificat serveur par le certificat LDAP CA

✓

ca-user-cert.cnf pour signer le certificat client par le certificat racine Root CA

✓

Il convient, si ce n'est déjà fait, de créer les répertoires fondamentaux: $dir, $dir/certs, $dir/private et $dir/newcerts.

Puis, lors de la toute première création de certificats, il faut initialiser le fichiers index.txt et serial. Pour cela il suffit de taper les commandes suivantes:

# touch index.txt

ce qui créera un fichier index.txt vide, et

# echo 01 > serial

qui créera un fichier serial avec 1 comme valeur initiale de numéro de certificat.

Création des «certificats d’autorité».

Le paramètre x509 de la requête ci-dessous permet d'avoir un certificat auto-signé:

root@machine:/racine# openssl req -x509 -config root-ca-cert.cnf -newkey rsa:4096 -out ca.pem -keyout private/ca.key -days 1826

Generating a 4096 bit RSA private key

...............................................................................++

..........................++

writing new private key to 'private/ca.key'

Enter PEM pass phrase:

Verifying - Enter PEM pass phrase: passe-rootCA

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Pays [FR]:

Etat, province ou departement [Herault]:

Ville [Montpellier]:

Organisation [Maison de la Teledetection]:

Unite organisationnelle [TETIS]:

Nom commun [MTD Root CA]:

Adresse mail []:mail_admin@mondomaine.net

Il est important ensuite de créer un fichier (symbolique) dont le nom est de la forme hash.0, dans laquelle hash est la valeur de hachage du DN.

Pour obtenir la valeur de hachage du fichier ca.pem par exemple, il suffit de taper la commande suivante:

root@machine:/racine# openssl x509 -hash -in ca.pem -noout

156152a2

Le fichier hash.0 est à placer dans le répertoire certs et doit pointer vers le vrai fichier ca.pem. Exemple:

root@machine:/racine# cd certs

root@machine:/racine/certs# ln -s ../ca.pem 156152a2.0

Ou bien, si on veut se la jouer:

root@machine:/racine# cd certs

root@machine:/racine/certs# ln -s ../ca.pem `openssl x509 -hash -in ../ca.pem -noout`.0

Si ceci n'était pas fait, il serait difficile de vérifier une chaîne de certificats.

Tout d'abord, on crée un certificat temporaire et une clé privée normale:

root@machine:/racine# openssl req -config req-subca-cert.cnf -newkey rsa:4096 -out templdapcacert.pem -keyout private/ldapca.key

Generating a 4096 bit RSA private key

..........................................................................................................................................................................++

..............................................................................................++

writing new private key to 'private/ldapca.key'

Enter PEM pass phrase: passe-ldapCA

Verifying - Enter PEM pass phrase: passe-ldapCA

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Pays [FR]:

Etat, province ou departement [Herault]:

Ville [Montpellier]:

Organisation [Maison de la Teledetection]:

Unite organisationnelle [TETIS]:

Nom commun [MTD LDAP CA]:

Adresse mail []: mail_admin@mondomaine.net

A ce moment le certificat signé n'est plus temporaire et il est donc automatiquement placé (grâce à la commande ci-dessous) dans le répertoire certs sous le nom serial.pem dans lequel serial est la valeur contenue dans le fichier serial (par exemple, le fichier créé sera 01.pem):

root@machine:/racine# openssl ca -config ca-subca-cert.cnf -cert ca.pem -in templdapcacert.pem -notext -out certs/ldapca.pem

Using configuration from ca-subca-cert.cnf

Enter pass phrase for /data-mail/srv-ldap/etc/ssl/teledetection/private/ca.key: passe-rootCA

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'FR'

stateOrProvinceName :PRINTABLE:'Herault'

localityName :PRINTABLE:'Montpellier'

organizationName :PRINTABLE:'Maison de la Teledetection'

organizationalUnitName:PRINTABLE:'TETIS'

commonName :PRINTABLE:'MTD LDAP CA'

emailAddress :IA5STRING:'mail_admin@mondomaine.net'

Certificate is to be certified until Oct 30 13:15:25 2020 GMT (4383 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

Cette commande affiche un résumé du certificat, confirmez si cela est correct. Il faut, bien sûr, donner le mot de passe du certificat d’autorité racine pour signer ce sous-certificat d’autorité.

La commande ci-dessus crée également un fichier ldapca.pem dans le répertoire certs. Pourquoi? Eh bien, si le fichier 01.pem est peut-être gentiment créé par openssl, son nom n'est pas très parlant à l'esprit. Il vaut mieux que le nom du fichier soit représentatif du certificat qu'il contient. Cela aide. Plus tard.

L'argument notext permet de ne pas ajouter la description textuelle du certificat dans le fichier final.

Il est important de rajouter les extensions de type ca si l'on veut que le certificat soit celui d'un CA; voir le fichier de configuration utilisé (ca-subca-cert.cnf)

L’option “-cert ca.pem” est obligatoire lorsque les certificats ne sont pas dans le répertoire normal décrit dans le fichier “openssl.cnf”.

La requête demande la phrase de passe du certificat de root CA. Puis, la base de données des certificats sera mise à jour (modification des fichiers serial et index.txt)

Le fichier templdapcacert.pem peut alors être détruit.

Même chose pour le fichier symbolique de la forme hash.0 que dans le cas du certificat ca.pem. Par exemple:

root@machine:/racine# cd certs

root@machine:/racine/certs# ln -s ldapca.pem c9ce0d54.0

ou bien:

root@machine:/racine# cd certs

root@machine:/racine/certs# ln -s ldapca.pem `openssl x509 -hash -inldapca.pem -noout`.0

Création du «certificats» du serveur ldap.

Le serveur LDAP tournera sur la machine nommée «srv-ldap». La clé privée du futur certificat sera appelée srv-ldap.key. C’est le même mécanisme que pour les certificats d’autorité. La commande à saisir est de la forme suivante:

root@machine:/racine# openssl req -config req-server-cert.cnf -out tempservercert.pem -keyout private/srv-ldap.key -newkey rsa:4096

Generating a 4096 bit RSA private key

...................................++

......++

writing new private key to 'private/srv-ldap.key'

Enter PEM pass phrase: passe-srv-ldap

Verifying - Enter PEM pass phrase: passe-srv-ldap

-----

You are about to be asked to enter information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Pays [FR]:

Etat, province ou departement [Herault]:

Ville [Montpellier]:

Organisation [Maison de la Teledetection]:

Unite organisationnelle [TETIS]:

Nom commun (ex: nom de la root CA) []: srv-ldap.domaine.net

Adresse mail []:mail_admin@mondomaine.net

root@machine:/racine# openssl ca -config ca-server.cert.cnf -cert certs/ldapca.pem -keyfile private/ldapca.key -in tempservercert.pem -notext -out certs/srv-ldap.pem

Using configuration from ca-server.cert.cnf

Enter pass phrase for private/ldapca.key:passe-ldapCA

Check that the request matches the signature

Signature ok

The Subject's Distinguished Name is as follows

countryName :PRINTABLE:'FR'

stateOrProvinceName :PRINTABLE:'Herault'

localityName :PRINTABLE:'Montpellier'

organizationName :PRINTABLE:'Maison de la Teledetection'

organizationalUnitName:PRINTABLE:'TETIS'

commonName :PRINTABLE:'srv-ldap.teledetection.fr'

emailAddress :IA5STRING:'mail_admin@mondomaine.net'

Certificate is to be certified until Oct 30 13:27:10 2010 GMT (730 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

On notera ici qu'il faut préciser quelle CA doit servir à signer le certificat. D'où la présence des deux arguments supplémentaire -cert et -keyfile. La signature exigera de donner la phrase de passe du certificat LDAP CA.

Ne pas oublier de créer un fichier hash.0 selon la méthode habituelle.

root@machine:/racine# cd certs

root@machine:/racine/certs# ln -s srv-ldap.pem `openssl x509 -hash -in srv-ldap.pem -noout`.0

Il peut être souhaitable de retirer la phrase de passe de la clé privée du certificat serveur. Par exemple, supposons que nous souhaitions supprimer la phrase de passe de la clé privée stockée dans le fichier «srv-ldap-free.key». Pour ce faire, nous tapons la commande suivante:

root@machine:/racine# openssl rsa -in private/srv-ldap.key -out private/srv-ldap-free.key

Enter pass phrase for private/srv-ldap.key:passe-srv-ldap

writing RSA key

Lecture d'un certificat

Pour afficher simplement au format texte un certificat contenu dans un fichier certificat.pem, il suffit de taper la commande:

# openssl x509 -text -noout -incertificat.pem

dans laquelle:

-text permet l'affichage complet du certificat au format texte

✓

-noout évite l'affichage du format binaire du certificat,

✓

-in permet de spécifier le nom du fichier contenant le certificat.

✓

Un simple mot de passe n'étant plus forcément suffisant pour assurer la sécurité d'un système (et dans notre cas d'un certificat), on demande à l'utilisateur de donner une phrase entière pour assurer une meilleure authentification.

Exemples de phrases:

homo homini lupus

✓

mignonne allons voir si la rose

✓

Ho combien de capitaines, combien de marins

Il est tout à fait envisageable d'avoir une phrase de passe limitée à un seul mot. C'est vrai que cela ressemble à un mot de passe. Mais techniquement c'est différent, ne l'oublions pas!

Si vous voulez supprimer une phrase de passe, allez lire «Suppression d’un certificat».

Test des certificats

✓

# openssl verify certs/mesange.pem

ou bien :

# openssl verify -CApathcerts certs/mesange.pem

permet de vérifier la chaîne de certification du certificat du serveur.

La deuxième version de la commande permet d'aider openssl à trouver où sont situés les fichiers de la forme hash.0.

Mais le mieux consiste à tester réellement les certificats.

Configuration du fichier slapd.conf

Trois clauses sont nécessaires pour un bon fonctionnement du serveur. Voici un exemple de définition. Vous devrez adapter ces définitions à votre cas dans le fichier /etc/ldap/slapd.conf.

TLSCACertificatePath/usr/share/ssl/certs

TLSCertificateFile /usr/share/ssl/certs/mesange.pem

TLSCertificateKeyFile/usr/share/ssl/private/mesange.key

La première clause permet de spécifier où sont situés les différents certificats, et en particulier les certificats des CA. Nécessaire si le serveur doit valider le certificat du client.

Les deux autres clauses (TLSCertificateFile et TLSCertificateKeyFile) permettent de spécifier le certificat du serveur et sa clé privée.

Une fois le fichier de configuration du serveur mis à jour, il convient de lancer correctement le serveur. Celui-ci doit pouvoir accepter aussi bien des demandes de connexions non sécurisées que mettant en oeuvre la couche TLS. Ceci signifie que le serveur doit généralement écouter 2 ports différents. Un port supportera les connexions normales, et l'autre les connexions de type TLS. La commande slapd permet ceci. Par exemple:

# slapd -d 5 -h "ldap://:9009/ ldaps://:9008" -f slapd.conf

Cette commande ordonne au serveur d'écouter les connexion normales sur le port 9009 et les connexions TLS sur le port 9008. Le paramètre «-d5» permet au serveur d'afficher ce qu'il fait, ce qui est très utile lors des tests.

Dans le cas d’une installation sur une Debian Etch, il faut modifier le fichier “/etc/default/slapd” avec cette option :

SLAPD_SERVICES="ldap:/// ldaps:///"

Notons que lors du démarrage du serveur, il vous sera demandé la phrase de passe du certificat serveur.

Il est également possible de tester TLS directement au dessus d'un seul port. Pour cela, il suffit de taper la commande suivante:

# slapd -d 5 -h ldap://:9009/ -f slapd.conf

Par contre, il faut que le client puisse utiliser l'extension "StartTLS".

Par exemple, avec le client ldapsearch:

# ldapsearch -Z -H ldap://machine:9009/ "(filtre)"

L'extension "StartTLS" est demandée par l'utilisation de l'argument supplémentaire «-Z».

Configuration du client ldapsearch

Le client ldapsearch doit pouvoir accéder aux certificats de CA pour être en mesure de valider le certificat du serveur.

Ceci se fait grâce à un fichier (ldaprc ou bien ldap.conf) dans lequel 2 clauses sont importantes:

TLS_CACERT/usr/local/ssl/ca.pem

TLS_CACERTDIR/usr/local/ssl/certs

La première clause indique quel est le fichier contenant le root CA. La deuxième clause donne le répertoire où sont stockés les différents certificats nécessaires à la validation.

Note: La première clause n'est pas fondamentalement nécessaire si dans le répertoire des certificats existe un lien symbolique vers le certificat du root CA.

Si vous utilisez un fichier ldaprc, et si dans ce fichier sont définies les deux clauses supplémentaires suivantes:

TLS_CERT/usr/local/ssl/certs/client.pem

TLS_KEY/usr/local/ssl/private/client.key

alors, lorsque vous lancerez une commande ldapsearch, la passphrase du certificat client sera demandée, si celle-ci existe bien entendu.

Création d'un certificat client

L'idée de principe est identique à la création d'un certificat serveur. Il faudra simplement choisir le bon fichier de configuration pour générer la requête de certificat, puis il faudra signer le certificat par une autorité de certification.

Je vous laisse faire vous-même vos propres essais. J'y suis arrivé; et comme vous ne pouvez pas être plus bête que moi (à moins d'être un idiot congénital), vous devriez y arriver vous aussi.

Fichiers de configuration utilisés