Authentification TLS OpenLDAP

J'essaie d'implémenter TLS selon https://help.ubuntu.com/lts/serverguide/openldap-server.html Lorsque j'essaie de modifier la base de données cn = config avec ce fichier ldif:

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/test-ldap-server_cert.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/test-ldap-server_key.pem

J'obtiens l'erreur suivante:

ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "cn=config"
ldap_modify: Other (e.g., implementation specific) error (80)

Qu'est-ce que je fais mal?

EDIT: lorsque j'essaie d'utiliser l'authentification simple, j'ai eu l'erreur suivante:

ldapmodify -x -D cn=admin,dc=example,dc=com -W -f certinfo.ldif
Enter LDAP Password:
ldap_bind: Invalid DN syntax (34)
        additional info: invalid DN

Je suivais le même guide et avais le même problème. Cela fonctionnera si vous effectuez les étapes pour "Resserrer la propriété et les autorisations" répertoriées après la commande ldapmodify incriminée en premier - à savoir:

sudo adduser openldap ssl-cert
sudo chgrp ssl-cert /etc/ssl/private
sudo chgrp ssl-cert /etc/ssl/private/ldap01_slapd_key.pem
sudo chmod g+X /etc/ssl/private
sudo chmod g+r /etc/ssl/private/ldap01_slapd_key.pem

et

sudo systemctl restart slapd.service

Eh bien, je ne sais pas s'il s'agit d'une solution ou simplement d'une solution de contournement, mais j'ai réussi à le faire fonctionner.

J'ai d'abord arrêté le slapd avec:

service slapd stop

Ensuite, je l'ai démarré en mode débogage:

slapd -h ldapi:/// -u openldap -g openldap -d 65 -F /etc/ldap/slapd.d/ -d 65

L'important est de le démarrer UNIQUEMENT avec ldapi: /// URL. Après son démarrage, j'ai exécuté la commande ldapmodify et les attributs ont été importés.

À la fin, j'ai arrêté le mode débogage et démarré le slapd normalement.

Pour faire suite à la réponse d'A. Gutierrez , la meilleure façon de vérifier l'accès à chaque fichier est de l'exécuter sudo -u openldap cat <filename>. J'ai regardé tous les fichiers plusieurs fois et ils avaient l'air d'avoir des autorisations correctement définies. Il s'est avéré être un problème de groupe pour openldap. Une fois que j'ai finalement compris cela, un simple sudo usermod -a -G ssl-cert openldapproblème l'a résolu pour moi.

Parfois, le problème se trouve dans le profil de l'aparmeur pour le service slapd. Assurez-vous que le profil de l'apparmeur a autorisé les chemins de certificat pour le démon.

C'est assez visuellement /etc/apparmor.d/usr.sbin.slapd. Par défaut, ce profil permet de lire les certificats dans les emplacements par défaut.

Apparmor devrait empêcher les actions non spécifiées pour l'exécutable du démon, malgré les autorisations Unix appropriées.

Comme je l'ai signalé dans ce bug sur Ubuntu Launchpad , ce problème peut également être causé par l'apparmeur. Habituellement, cela apparaîtra dans le syslog comme un refus d'accès.

Le correctif insère la ligne suivante dans /etc/apparmor.d/usr.sbin.slapd:

/etc/letsencrypt/** r,

puis actualiser le profil:

# apparmor_parser -vr usr.sbin.slapd
# service apparmor restart

J'ai aussi ce problème. Le problème est que l'utilisateur exécutant slapd n'avait pas accès aux fichiers de certificats. Vérifiez que le propriétaire de ces fichiers est un utilisateur openldap.

Pour moi, le problème était dans le mauvais ordre des enregistrements - voici celui qui a fonctionné:

dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ssl/certs/cm_ca_cert.pem
-
# This never worked for me, no idea why
#add: olcTLSCipherSuite
#olcTLSCipherSuite: TLSv1+RSA:!NULL
#-
replace: olcTLSVerifyClient
olcTLSVerifyClient: never
-
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ssl/certs/cm_server.pem
-
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ssl/private/cm_server.key

Malheureusement, cela semble être l'erreur "par défaut" que vous obtenez pour à peu près n'importe quoi. La réponse de @ wulfsdad le corrige généralement.

Une autre chose que j'oublie toujours, c'est que par défaut sur ubuntu slapd veut la clé au format openssl. J'ai l'habitude mais les touches PCKS # 8 dedans et je m'attends à ce que ça marche (ce qui pour être juste devrait). Si vous avez essayé toutes les réponses ci-dessus, assurez-vous également que la clé a le bon format. Lorsque vous recherchez l'erreur sur Google, vous lisez généralement les mauvaises autorisations et vous vous demandez pourquoi apache fonctionne avec la clé que slapd n'aime pas.