Pour éviter que le dialogue entre les serveurs LDAP puisse être capté, et notamment lors des phases de changement de mot de passe, il est conseillé de crypter les échanges entre le serveur maître et les serveurs esclaves.
Pour cela, nous allons mettre en place la couche TLS en utilisant OpenSSL.
Quelques liens qui m’ont permis de mettre au point la configuration :
http://www-lor.int-evry.fr/ michel/LDAP/SASL/TLS-SSL.html
mais également sur la documentation officielle openldap :
http://www.openldap.org/doc/admin24/
Et sur le cryptage SSL :
http://www.commentcamarche.net/contents/crypto/certificat.php3
http://fr.wikipedia.org/wiki/X.509
http://fr.wikipedia.org/wiki/Certificat_électronique
http://fr.wikipedia.org/wiki/Cryptographie_asymétrique
http://www.frpki.org/index.php?/openssl_base.html
Le cryptage SSL (remplacé depuis par TLS) est basé sur l’utilisation du cryptage asymétrique. Son principe est le suivant.
Deux clés sont générées. Un message crypté avec une des deux clés peut être déchiffré avec l’autre. Il suffit de transmettre une des deux clés à son correspondant pour que celui-ci puisse, non seulement décrypter le message que nous venons de lui envoyer, mais également crypter un message que nous pourrons décrypter. Dans la pratique, une seule des deux clés est transmise à l’ensemble des correspondants, la clé publique. L’autre clé est conservée précieusement et ne doit jamais être transmise, la clé privée.
Dans un échange, il est important de pouvoir s’assurer que le correspondant est bien celui qu’il dit être. Pour cela, la clé publique est signée par une autorité reconnue, en qui on peut faire confiance : le tiers de confiance. La clé publique est ainsi transmise à l’intérieur d’un certificat, qui contient non seulement la clé publique, mais également le nom du serveur à laquelle elle se réfère (pour une clé correspondant à un serveur), le nom de l’autorité qui a signé le certificat et la signature du certificat.
La signature du certificat fonctionne ainsi : l’ensemble des informations du certificat est haché (compressé en une empreinte unique). Cette empreinte est cryptée avec la clé privée du certificateur, et est ensuite rajoutée dans le certificat.
Pour s’assurer de la validité de la clé publique, il faut donc extraire l’empreinte cryptée, la déchiffrer avec la clé publique du certificateur, puis la comparer avec l’empreinte que nous pouvons calculer.
L’ensemble de ces mécanismes sont décrits dans une norme, la norme X.509.
Pour résumer :
Nous avons donc besoin de quatre objets :
Deux possibilités s’offrent à nous : soit nous signons nous-mêmes nos clés publiques, soit nous faisons appel à une autorité de certification pour réaliser cette signature.
Pour commencer, nous allons signer nous-mêmes nos clés publiques. C’est la seule solution si vous ne disposez pas d’une autorité de certification.
Créons la clé privée de l’autorité de certification racine :
openssl req -new -x509 -keyout cacert.pem -out cacert.pem -days 3650
Lors de la procédure, le programme demande un mot de passe : c’est celui qui devra être fourni à chaque demande de signature d’un certificat.
Nous allons maintenant générer le certificat de l’autorité de certification, qui va être utilisé pour valider les certificats des serveurs ; ce certificat contient donc la clé publique de l’autorité de certification :
openssl x509 -in cacert.pem -out cacert.crt
Nous allons générer la clé privée du serveur :
openssl genrsa -out server.key 1024
Puis nous la protégeons pour éviter que quiconque, à part root ou les process autorisés, puissent y accéder :
chmod 600 server.key
A partir de la clé privée, nous allons préparer une requête qui sera transmise à l’autorité de certification. Cette requête contient non seulement la clé publique, mais également un certain nombre d’informations, dont le nom du serveur.
openssl req -new -key server.key -out server.csr
Une fois la commande lancée, un certain nombre de champs vont devoir être renseignés. Les champs laissés à vide doivent comporter un point (.).
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:.
Locality Name (eg, city) []:.
Organization Name (eg, company) [Internet Widgits Pty Ltd]: MA SOCIETE
Organizational Unit Name (eg, section) []: .
Common Name (eg, YOUR name) []:girondetest2
Email Address []: .
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Les deux derniers champs sont laissés à vide.
Attention : le Common Name doit impérativement correspondre au nom du serveur qui va être utilisé dans les requêtes. Si vous utilisez un serveur DNS, vous devrez donner le nom complet. Sinon, indiquez uniquement le nom de la machine (et renseignez, sur les clients, le fichier hosts pour faire la correspondance). De nombreux soucis de fonctionnement de la couche TLS sont liés à une gestion des noms erronée...
Si vous n’utilisez pas les services d’une autorité d’enregistrement, vous devez générer vous même le certificat :
openssl x509 -req -days 3650 -in server.csr -CA cacert.pem -out server.crt
Si vous avez un message d’erreur du type :
cacert.srl: No such file or directory
il faut rajouter l’option suivante : -CAcreateserial, qui va créer le fichier contenant le numéro de série. La commande devient donc :
openssl x509 -req -in server.csr -CA cacert.pem -CAkey cacert.pem -out server.crt -Cacreateserial
Ne lancez cette commande qu’une seule fois...
Certaines applications ont besoin d'un certificat autosigné, quand il n'est pas possible d'en obtenir un (domaine privé, par exemple).
Une fois la requête de création du certificat exécutée, lancez la commande suivante :
openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt
qui permet de créer un certificat (server.crt) autosigné.
Si vous disposez d’une autorité de certification, envoyez le fichier qui vient d’être généré (server.csr) pour recevoir, en retour, la clé publique. En général, les champs Organization Name et Organizational unit name vous sont imposés : consultez votre autorité de certification pour connaître les bonnes informations à fournir.
Il vous faut également récupérer le certificat racine (équivalent du cacert.crt, la clé publique de l’autorité de certification) qui permettra de vérifier la validité du certificat qui vous sera fourni par l’autorité de certification.
Pour visualiser le contenu d’une clé privée :
openssl rsa -in server.key -text
Pour visualiser la clé publique associée :
openssl rsa -in server.key -pubout
Pour visualiser un certificat :
openssl x509 -in server.crt -text -noout
Pour vérifier la validité du certificat :
openssl verify -CAfile cacert.crt server.crt
Recopiez la clé publique (server.crt), la clé privée (server.key) et le certificat racine (cacert.crt) dans le dossier /etc/ldap/. Modifiez les droits pour que :
Editez le fichier /etc/ldap/ldap.conf, et rajoutez la ligne (ou modifiez-là) :
TLS_CACERT /etc/ldap/cacert.crt
qui va permettre à tous les processus LDAP de vérifier les clés à partir du certificat racine.
Par défaut, webmin génère ses propres certificats. Il est possible de lui faire utiliser les certificats que nous venons de générer.
Pour cela :
Pour que les accès à l’annuaire LDAP à partir de Ldap Account Manager soient protégés, nous aurons besoin de basculer la liaison en mode SSL. Là aussi, nous pouvons intégrer les certificats que nous venons de générer dans Apache.
Recopiez les certificats dans le dossier /etc/apache2, puis éditez le fichier /etc/apache2/sites-available/default-ssl :
SSLCertificateFile /etc/apache2/server.crt
SSLCertificateKeyFile /etc/apache2/server.key
Activez le support ssl dans Apache :
a2enmod ssl
a2ensite default-ssl
Redémarrez ensuite le service apache :
service apache2 restart
Les certificats sont utilisés par de nombreux processus, et leur emplacement décrit dans de nombreux fichiers.
Plutôt que de recopier les certificats dans chaque dossier spécifique d’un service, il peut être judicieux de les stocker à un seul endroit.
Pour cela, recopiez la clé primaire dans le dossier /etc/ssl/private, et donnez lui les droits suivants :
chmod 640 /etc/ssl/private/server.key
chown root:ssl-cert /etc/ssl/private/server.key
Recopiez la clé publique et le certificat racine dans /etc/ssl/certs, et vérifiez que les fichiers sont bien en mode 644.
Nous allons créer un lien vers la valeur de hachage du fichier cacert.crt (la clé racine) :
cd /etc/ssl/certs
ln -s cacert.crt `openssl x509 -hash -in cacert.crt -noout`.0
Ce lien va permettre de retrouver très rapidement la clé de l’autorité de certification pour pouvoir vérifier la clé publique. L’empreinte est calculée à partir de la valeur Subject du certificat, qui figure dans notre certificat public et dans le certificat de l’autorité de certification.
Notre clé privée n’est accessible qu’au compte root et au groupe ssl-cert. Pour que le service Ldap puisse accéder à cette clé, nous allons intégrer le compte openldap dans le groupe ssl-cert :
usermod -a -G ssl-cert openldap
Il ne reste plus qu’à modifier les chemins vers les certificats, par exemple, dans le fichier /etc/ldap/slapd.conf :
TLSCertificateFile /etc/ssl/certs/server.crt
TLSCertificateKeyFile /etc/ssl/private/server.key
TLSCACertificateFile /etc/ssl/certs/cacert.crt
Il est fortement conseillé de n’avoir qu’un seul certificat racine : cela simplifie grandement la configuration des clients.
De fait, l’étape de génération du certificat racine (paragraphe 1 Créer le certificat racine, page 12) n’est à réaliser qu’une seule fois.
Sur les autres serveurs, après avoir généré la clé privée et la demande de clé publique, il faut :
Ainsi, le même certificat racine sera utilisé pour valider l’ensemble des certificats de votre infrastructure.