Sécuriser 389 Directory Server sous CentOS 7

Voici le troisième article dans notre série sur l’authentification centralisée avec 389 Directory Server. Les deux précédents articles traitaient de l’installation du serveur d’annuaires et de la création des utilisateurs. Dans l’état actuel des choses, rien ne nous empêcherait de connecter un poste client à notre serveur pour lui permettre de récupérer les données d’authentification. Le seul problème, c’est que les données des utilisateurs comme les identifiants et les mots de passe transiteraient en clair dans le réseau local, ce qui n’est pas idéal en termes de sécurité. L’article du jour se penche donc sur la question de la sécurité des connexions.

• Créer une autorité de certification TLS
• Initialer la base de données NSS
• Générer une demande de certificat CSR
• Signer le certificat
• Importer le certificat du CA
• Importer le certificat du serveur
• Activer les connexions sécurisées
• Gérer le démarrage du service

Créer une autorité de certification TLS

Différents chemins mènent à Saint-Bauzille-de-Putois, comme le dit un proverbe un peu moins connu. La première chose que nous devons faire, c’est mettre en place une autorité de certification TLS. Nous avons le choix entre plusieurs façons de faire. Je n’aime pas me compliquer la vie inutilement, mon choix se porte donc sur Easy-RSA. La mise en place d’une autorité de certification TLS avec Easy-RSA est décrite en détail dans cet article.

Initialer la base de données NSS

389 Directory Server stocke les certificats dans la base de données NSS (Network Security Services). Cette base doit être initialisée avant la première utilisation.

Retournez dans la console d’administration > Server Group > Directory Server > Open. Dans la fenêtre subséquente, cliquez sur Manage Certificates dans l’onglet Tasks.

Initialisez la base NSS en choisissant un mot de passe.

Générer une demande de certificat CSR

La prochaine étape consiste à générer une demande de certificat (Certificate Signing Request).

Dans l’onglet Server Certs, cliquez sur Request > Request certificate manually > Next.

Renseignez le formulaire de la demande de certificat et cliquez sur Next.

Définissez les paramètres de la clé.

Renseignez le mot de passe de la clé privée.

Cliquez sur Save to file.

Enregistrez le fichier dans votre répertoire utilisateur en lui donnant un nom cohérent, par exemple server-cert.csr, et cliquez sur Done.

Signer le certificat

La prochaine étape consiste à signer notre demande de certificat. C’est ce que nous allons faire très simplement en utilisant Easy-RSA.

Dans un premier temps, nous devons importer la demande de certificat.

$ cd easy-rsa-3.0.7/easyrsa3/
$ ./easyrsa import-req ~/server-cert.csr server-cert

Using SSL: openssl OpenSSL 1.0.2k-fips 26 Jan 2017

The request has been successfully imported with a short name of: server-cert
You may now use this name to perform signing operations on this request.

Il ne reste plus qu’à le signer en précisant qu’il s’agit d’un certificat de type server.

$ ./easyrsa sign-req server server-cert

Using SSL: openssl OpenSSL 1.0.2k-fips  26 Jan 2017

You are about to sign the following certificate.
Please check over the details shown below for accuracy. Note that this request
has not been cryptographically verified. Please be sure it came from a trusted
source or that you have verified the request checksum with the sender.

Request subject, to be signed as a server certificate for 1080 days:

subject=
    countryName               = FR
    stateOrProvinceName       = Gard
    localityName              = Montpezat
    organizationName          = Microlinux
    organizationalUnitName    = IT
    commonName                = amandine.microlinux.lan

Type the word 'yes' to continue, or any other input to abort.
  Confirm request details: yes

...

Write out database with 1 new entries
Data Base Updated

Certificate created at: ~/easy-rsa-3.0.7/easyrsa3/pki/issued/server-cert.crt

Le certificat signé server-cert.crt est désormais disponible dans l’arborescence d’Easy-RSA, dans le répertoire pki/issued.

Importer le certificat du CA

Maintenant, nous devons importer le certificat de l’autorité de certification (CA ou Certificate Authority). Retournez dans la console d’administration et rendez-vous dans la section Manage Certificates. Ouvrez l’onglet CA Certs et cliquez sur Install.

Choisissez l’option in this local file et cliquez sur Browse.

Naviguez dans l’arborescence de Easy-RSA, sélectionnez le fichier pki/ca.crt et cliquez sur Next.

Vérifiez les informations du certificat.

Confirmez le type de certificat.

Acceptez le choix par défaut pour le type de connexion.

Si tout s’est bien passé, le certificat apparaît dans la fenêtre CA Certs.

Importer le certificat du serveur

À présent, nous pouvons importer le certificat du serveur. Ouvrez l’onglet Server Certs, cliquez sur Install, choisissez l’option in this local file, cliquez sur Browse, sélectionnez le fichier server-cert.crt dans le répertoire pki/issued de l’arborescence d’Easy-RSA et cliquez sur Next.

Là aussi, vérifiez les informations du certificat, confirmez le type et saisissez le mot de passe pour la clé privée.

Le certificat du serveur a été importé avec succès.

Activer les connexions sécurisées

Maintenant que les certificats divers et variés sont installés, nous pouvons activer TLS. Dans la console d’administration, cliquez sur Server Group > Directory Server > Open. Dans la fenêtre subséquente, ouvrez l’onglet Configuration. Dans la section Network Settings, notez le port utilisé pour les connexions sécurisées (Encrypted Port).

Ouvrez l’onglet Encryption, cochez Enable SSL for this server et Use this cipher family: RSA. Vérifiez si l’option Certificate affiche bien le certificat server-cert.

Gardez les autres options telles quelles, et ne cochez surtout pas Use SSL in Console, sous peine de vous tirer dans le pied.

Cliquez sur Save et prenez note des avertissements divers et variés qui s’affichent.

Gérer le démarrage du service

La console d’administration nous a averti que l’activation de TLS nécessitait un redémarrage du service pour prendre effet. Or, voilà comment se présentent les choses.

$ sudo systemctl restart dirsrv.target
Enter PIN for Internal (Software) Token: *********

Dorénavant, le service requiert la saisie du mot de passe de la base NSS pour démarrer. Ce qui signifie qu’il ne peut plus se lancer de manière autonome au démarrage du serveur.

Pour éviter d’avoir à saisir le mot de passe à chaque redémarrage du service, on peut ranger le mot de passe dans un fichier pin.txt.

$ sudo vim /etc/dirsrv/slapd-amandine/pin.txt

Voici la syntaxe qu’il faudra utiliser.

Internal (Software) Token:mot_de_passe

Étant donné que le mot de passe est stocké en clair, il faut impérativement restreindre les permissions de ce fichier.

$ sudo chown dirsrv:dirsrv /etc/dirsrv/slapd-amandine/pin.txt
$ sudo chmod 0400 /etc/dirsrv/slapd-amandine/pin.txt

Cette solution n’est pas idéale en termes de sécurité. La démarche la plus sûre consiste sans doute à gérer le service manuellement et saisir le mot de passe à chaque démarrage.

Notre serveur est désormais capable de gérer des connexions sécurisées. Dans notre prochain article, nous allons tenter de connecter les postes clients du réseau pour leur permettre de s’authentifier.

La rédaction de cette documentation demande du temps et des quantités significatives de café espresso. Vous appréciez ce blog ? Offrez un café au rédacteur en cliquant sur la tasse.