Configuration du LDAPS avec SSL/TLS
Il a été défini dans le cahier des charges de cette infrastructure LDAP de démonstration d’utiliser le protocole LDAPS, dans la mesure où tous les clients LDAP seraient compatibles.
Afin de réaliser cette opération de configuration du protocole LDAPS, il faut au préalable créer un certificat personnel pour le serveur LDAP (nommé CSR), et l’émettre à une autorité de certification officielle, reconnue sur la toile (Verisign, Digicert), afin qu’il soit signé. Le certificat ainsi obtenu (CRT, PEM, DER) pourra être appliqué dans la configuration du serveur LDAP.
Voici ci-dessous un exemple réalisé sous RHEL6 à l’aide des commandes openssl.
# Création du certificat avec une clé RSA de 2048 bits (le minimum à mettre) 
# On produit donc la clé privée dans le fichier : ldap01.key 
# Et le CSR dans le fichier :  ldap01.csr 
# Lors de la création de ce CSR, plusieurs informations seront  
demandées telles que ’ Country Name,  Locality Name, etc. 
# Portez une attention particulière sur « Common Name », car c’est ce champ 
qui sera utilisé pour vérifier l’identité de votre serveur sur Internet et 
devra donc correspondre avec l’entrée DNS publiée sur le Net. 
 
[root@ldap01]# openssl req -new -newkey rsa:2048 -nodes -keyout ldap01.key 
-out ldap01.csr 
Generating a 2048 bit RSA private key 
....................+++ 
.....................................................................+++ 
writing new private key to ’ldap01.key’ 
----- 
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. 
----- 
Country Name (2 letter code) [XX]:FR 
State or Province Name (full name) []: 
 
Locality Name (eg, city) [Default City]:MONACO 
Organization Name (eg, company) [Default Company Ltd]:Entreprise SA 
Organizational Unit Name (eg, section) []:GGS SHARP 
Common Name (eg, your name or your server’s hostname) 
[]:ldap01.sharp.entreprise.com 
Email Address []: 
 
Please enter the following ’extra’ attributes 
to be sent with your certificate request 
A challenge password []: 
An optional company name []: 
[root@ldap01 certs]# 
Les deux fichiers ci-dessous seront ainsi disponibles :
root@ldap01 certs]# ls -lrt 
total 72 
-r--------. 1 root root    45 Sep 22  2015 password 
-rw-r--r--. 1 root root 16384 Sep 22  2015 secmod.db 
-rw-r--r--. 1 root root 16384 Sep 22  2015 key3.db 
-rw-r--r--. 1 root root 65536 Sep 22  2015 cert8.db 
-rw-r--r--  1 root root  1704 Jun  9 15:03 ldap01.key      # La clef 
privée à conserver sur le serveur 
-rw-r--r--  1 root root  1017 Jun  9 15:03 ldap01.csr      # Le CSR à 
envoyer à l’autorité de certification
Le fichier ldap01.csr ainsi produit doit maintenant être envoyé à l’autorité de certification afin qu’il soit enregistré et signé. Cela se traduira généralement par la réception de deux fichiers (.crt) : le certificat public du serveur signé et le certificat public de l’autorité de certification lui-même qui peut être utile à déployer sur des clients LDAP de notre organisation.
¬
Le certificat du serveur ainsi créé est indissociable de sa clé privée. Bien qu’il soit communiqué par le serveur lui-même lors de l’établissement d’une connexion à son service, il ne pourra donc pas être utilisé par autre serveur sans la clé privée.
Il faudra maintenant copier ces fichiers dans le répertoire /etc/openldap/certs, changer les informations propriétaire (ldap:ldap) et mettre des droits restrictifs (surtout pour la clé privée) :
[root@ldap01 certs]# pwd 
/etc/openldap/certs 
[root@ldap01 certs]# ls -lrt 
total 96 
-rw-r--r--. 1 root root 16384 Sep 22  2015 secmod.db 
-r--------. 1 root root    45 Sep 22  2015 password 
-rw-r--r--. 1 root root 16384 Sep 22  2015 key3.db 
-rw-r--r--. 1 root root 65536 Sep 22  2015 cert8.db 
-rw-r--r--  1 ldap ldap  1716 Jun 23  2016 DigiCertCA.crt 
-r--------  1 ldap ldap  1704 Jul 26  2016  ldap01.key 
-rw-r--r--  1 ldap ldap  1946 Jul 29  2016  ldap01.crt 
[root@ldap01 certs]#
La prochaine étape consiste à configurer le service LDAP afin d’activer l’écoute sur le port sécurisé 636/TCP. Pour ce faire, il faut éditer le fichier : /etc/sysconfig/ldap afin d’y modifier la valeur du paramètre SLAPD_LDAPS à la valeur yes.
Exemple
# Run slapd with -h "... ldaps:/// ..." 
#   yes/no, default: no 
SLAPD_LDAPS=yes
Ensuite, il faut redémarrer le service et vérifier qu’il écoute désormais sur les ports LDAP sécurisé et non sécurisé.
[root@ldap01 sysconfig]# ps -aef | grep -i slapd 
root      2222  2111  0 08:58 pts/0    00:00:00 grep -i slapd 
ldap     23801     1  0 Apr03 ?        00:57:21 /usr/sbin/slapd 
-h  ldap:/// ldaps:/// ldapi:/// -u ldap 
# 
[root@ldap01 sysconfig]# netstat -atunp | grep slapd 
tcp      0     0 0.0.0.0:636      0.0.0.0:*     LISTEN      23801/slapd 
tcp      0     0 0.0.0.0:389     0.0.0.0:*      LISTEN      23801/slapd
Il faut maintenant charger le certificat dans la configuration de notre serveur LDAP avec le mode de configuration dynamique (OLC). Les deux méthodes déjà évoquées sont ici aussi disponibles : en ligne de commande via un fichier LDIF ou bien à l’aide d’un navigateur LDAP.
[root@ldap01 ldif_files]# ldapmodify -D "cn=config" -W -f addssl.ldif 
Enter LDAP Password:  
modifying entry "cn=config" 
 
# Avec dans le fichier addssl.ldif : 
 
dn: cn=config 
changetype: modify 
add: olcTLSCACertificateFile 
olcTLSCACertificateFile: /etc/openldap/certs/DigiCertCA.crt 
 
dn: cn=config 
changetype: modify 
add: olcTLSCertificateFile 
olcTLSCertificateFile: /etc/openldap/certs/ldap01.crt 
 
dn: cn=config 
changetype: modify 
add: olcTLSCertificateKeyFile 
olcTLSCertificateKeyFile: /etc/openldap/certs/ldap01.key 
 
dn: cn=config 
changetype: modify 
add: olcTLSProtocolMin 
olcTLSProtocolMin: 3.1 
 
dn: cn=config 
changetype: modify 
add: olcTLSVerifyClient 
olcTLSVerifyClient: never
L’attribut olcTLSVerifyClient a été ajouté à la configuration et permet de spécifier au serveur LDAP la manière dont il doit réagir avec un client LDAP sollicitant l’établissement d’une connexion sécurisée LDAPS. En effet, le serveur LDAP peut très bien lui aussi vouloir s’assurer de l’authenticité de ses clients LDAP... ce qui peut complexifier l’établissement de connexions.
Ainsi, cet attribut peut se voir attribuer quatre valeurs : never | allow | try | demand qui vont de la plus permissive à la plus restrictive. Par défaut, la valeur de cet attribut est fixée à : never signifiant que le serveur LDAP ne validera jamais les certificats de ses clients et laissera donc quiconque s’y connecter.
Il y a également l’ajout de l’attribut olcTLSProtocolMin qui permettra de ne pas être impacté par la vulnérabilité "POODLE" référencée [CVE-2014-3566]. En effet, une brèche a été découverte jusqu’à la version SSL 3.0 qui permet une attaque de type "Man in the middle".
Ainsi, afin de se protéger de cette attaque, nous devons fixer la valeur de cet attribut à : 3.1, contraignant obligatoirement l’usage de TLS1.0 et supérieur pour l’établissement de connexions SSL/TLS.
¬
Attention : si le client SSL ne possède pas cette version, il ne sera donc pas possible d’établir une communication sécurisée avec le serveur LDAP. Il faut donc s’assurer que les clients LDAP disposent bien des dernières versions des librairies SSL.
¬
Si un crash du daemon "slapd" lors de l’ajout de cet attribut devait survenir, il faut lancer la commande service slapd restart.
¬
À la place de l’attribut olcTLSProtocolMin, il est possible de désactiver le SSL 3.0 en utilisant l’attribut TLSCipherSuites comme suit :  TLSCipherSuites HIGH:!MEDIUM:!LOW:TLSv1:!SSLv3:!SSLv2
Tester maintenant que le serveur LDAP répond bien aux requêtes LDAPS et plus particulièrement à partir de la version TLS1.0 à l’aide de la commande openssl.
# 
# Test de connexion en SSL 3.0 
# 
[root@test01 ~]# openssl s_client -connect ldap01:636 -ssl3 
CONNECTED(00000003) 
140537404282696:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong 
version number:s3_pkt.c:339: 
--- 
no peer certificate available 
--- 
No client certificate CA names sent 
--- 
SSL handshake has read 5 bytes and written 7 bytes 
--- 
New, (NONE), Cipher is (NONE) 
Secure Renegotiation IS NOT supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
    Protocol  : SSLv3 
    Cipher    : 0000 
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None 
    Krb5 Principal: None 
    PSK identity: None 
    PSK identity hint: None 
    Start Time: 1491994649 
    Timeout   : 7200 (sec) 
    Verify return code: 0 (ok) 
--- 
[root@test01 ~]#

# 
# Test de connexion en TLS 1.0 
# 
[root@test01 ~]# openssl s_client -connect ldap01:636 -tls1 
CONNECTED(00000003) 
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN =  
DigiCert High Assurance EV Root CA 
verify return:1 
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN =  
DigiCert SHA2 High Assurance Server CA 
verify return:1 
depth=0 C = FR, ST = Meudon, L = Meudon, O = ENTREPRISE SA,  
CN = *.exemple.com 
verify return:1 
--- 
Certificate chain 
 0 s:/C=FR/ST=Meudon/L=Meudon/O=ENTREPRISE SA/CN=*.exemple.com 
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 
High Assurance Server CA 
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 
High Assurance Server CA 
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High  
Assurance EV Root CA 
--- 
Server certificate 
-----BEGIN CERTIFICATE----- 
MIIFWjCCBEKgAwIBAgIQCTUtX4KJNbipJQfdh2+nTzANBgkqhkiG9w0BAQsFADBw 
.... 
.... 
-----END CERTIFICATE----- 
subject=/C=FR/ST=Meudon/L=Meudon/O=ENTREPRISE SA/CN=*.exemple.com 
issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High 
Assurance Server CA 
--- 
No client certificate CA names sent 
Server Temp Key: ECDH, prime256v1, 256 bits 
--- 
SSL handshake has read 3078 bytes and written 289 bytes 
--- 
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA 
Server public key is 2048 bit 
Secure Renegotiation IS supported 
Compression: NONE 
Expansion: NONE 
SSL-Session: 
    Protocol  : TLSv1 
    Cipher    : ECDHE-RSA-AES128-SHA 
    Session-ID: 
5CF90A5BC1FDE91E7911DB51B52155059B28AAB80C0869C2432C0186CAEABDA2 
    Session-ID-ctx: 
    Master-Key: 
1B12DC12504FA997DCD6526AF44812381A4E1A0C8AEDC33A87A2DE6214F11151203F
6D4BD296A30251823EAFAB7EEDA8 
    Key-Arg   : None 
    Krb5 Principal: None 
    PSK identity: None 
    PSK identity hint: None 
    Start Time: 1491994837 
    Timeout   : 7200 (sec) 
    Verify return code: 0 (ok) 
---
Un test peut également être réalisé par l’exécution d’une commande ldapsearch. 
Exemple
[root@test01 ~]# ldapsearch -H ldaps://ldap01 -D  
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base -LLL 
Enter LDAP Password: 
dn: dc=exemple,dc=com 
objectClass: top 
objectClass: domain 
dc: exemple
¬
Ne pas utiliser le paramètre -Z qui établit une connexion "StartTLS"... c’est-à-dire une connexion sécurisée au travers du port non sécurisé LDAP (389/TCP).