Phase 1 : Mise en place de l'Autorité de Certification (CA)
Pour sécuriser les échanges LDAP, il est nécessaire de disposer d'une autorité de certification. Dans cet exemple, le serveur LDAP fera office de CA pour lui-même. Assurez-vous que l'horloge système est synchronisée avant de commencer.
# Initialisation de l'environnement PKI
cd /etc/pki/CA/
echo "1000" > /etc/pki/CA/serial
touch /etc/pki/CA/index.txt
# Création de la clé privée de la CA avec des permissions restreintes
(umask 077; openssl genrsa -out private/root_ca_key.pem 4096)
# Génération du certificat racine (valide 10 ans)
openssl req -new -x509 -key private/root_ca_key.pem -out root_ca_cert.pem -days 3650 \
-subj "/C=FR/ST=Paris/L=Paris/O=Infrastructure/OU=Security/CN=ca.mondomaine.local"
Phase 2 : Création de la demande de signature (CSR)
Pour 389-DS (ou Red Hat Directory Server), la méthode recommandée consiste à générer la demande directement depuis la console d'administration ou l'interface de gestion.
- Accédez à la section Manage Certificates.
- Définissez un mot de passe pour le jeton logiciel (Security Device). Ce PIN sera requis à chaque démarrage du service.
- Initiez la création d'une demande de certificat pour le serveur (Server Certificate Request).
- Remplissez les informations d'identité (DN) en veillant à ce que le Common Name (CN) corresponde exactement au FQDN du serveur.
- Exportez ou enregistrez le fichier CSR obtenu (par exemple :
server_req.csr).
Phase 3 : Signature du certificat serveur par la CA
Une fois le fichier CSR récupéré, utilisez l'autorité de certification créée précédemment pour émettre le certificat final.
# Signature de la requête
openssl ca -in /tmp/server_req.csr -out /etc/pki/CA/server_cert.crt -days 3650
Note sur les erreurs de politique : Si OpenSSL rejette la signature en raison de champs différents entre la CA et la requête (comme l'organisation), modifiez le fichier /etc/pki/tls/openssl.cnf en remplaçant policy = policy_match par policy = policy_anything.
Phase 4 : Importation des certificats
Retournez dans la console de gestion de 389-DS pour finaliser l'installation :
- Importez le certificat serveur signé (
server_cert.crt). - Importez le certificat de la CA (
root_ca_cert.pem) en tant qu'autorité de confiance.
Phase 5 : Activation du protocole TLS
Activez l'option de sécurité dans les paramètres de l'instance LDAP via la console. Un redémarrage du service est indispensable.
# Redémarrage de l'instance
systemctl restart dirsrv.target
Lors du redémarrage, le système vous demandera de saisir le PIN configuré à l'étape 2.
Phase 6 : Validation et configuration du client
Pour tester la connexion sécurisée avec ldapsearch, le client doit faire confiance à la CA.
# Configuration du client OpenLDAP
echo "TLS_CACERT /etc/openldap/certs/root_ca_cert.pem" >> /etc/openldap/ldap.conf
cp /etc/pki/CA/root_ca_cert.pem /etc/openldap/certs/
# Test de connexion avec StartTLS (-ZZ force l'utilisation du TLS)
ldapsearch -ZZ -h directory.mondomaine.local -x -b "dc=mondomaine,dc=local"
Astuces d'administration
Désactivation d'urgence du TLS
Si le serveur ne démarre plus suite à une mauvaise configuration TLS, vous pouvez désactiver la sécurité manuellement dans le fichier dse.ldif :
# Localiser et modifier le paramètre nsslapd-security
# Emplacement type : /etc/dirsrv/slapd-INSTANCE/dse.ldif
nsslapd-security: off
Automatisation de la saisie du PIN
Pour éviter la saisie manuelle du mot de passe au boot, créez un fichier pin.txt :
echo 'Internal (Software) Token:MonMotDePasseSecret' > /etc/dirsrv/slapd-INSTANCE/pin.txt
chmod 600 /etc/dirsrv/slapd-INSTANCE/pin.txt
Importation via la ligne de commande (certutil)
Si l'interface graphique échoue, utilisez les outils NSS :
# Importation de la CA
certutil -d /etc/dirsrv/slapd-INSTANCE/ -A -i root_ca_cert.pem -n "RootCA" -t "CT,CT,CT"
# Importation du certificat serveur
certutil -d /etc/dirsrv/slapd-INSTANCE/ -A -i server_cert.crt -n "Server-Cert" -t "u,u,u"