1 votes

PrashantN avatar

LDAP + TLS - comportement différent sur deux machines

Demandé el 31 de Octobre, 2011
Quand la question a-t-elle été
1453 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

Machines :

  1. debian wheezy
  2. suse 11

des commandes :

  1. ldapsearch -ZZ -h ad.unsw.edu.au -x
  2. perl -we "use Net::LDAP; print Net::LDAP->new ('ad.unsw.edu.au')->start_tls(verify => 'require', capath => '/etc/ssl/certs/')->{errorMessage}"

les résultats :

  • machine 1, commande 1 : TLS : le nom d'hôte ne correspond pas au CN du certificat du pair
  • machine 1, commande 2 : fonctionne
  • machine 2, commande 1 : fonctionne
  • machine 2, commande 2 : Impossible de déterminer le nom d'hôte du pair pour la vérification

je ne peux pas expliquer cette incohérence et je veux vraiment que la commande 2 fonctionne sur la machine 2. des idées ?

après un strace, il semble que debian-ldapsearch cherche à /etc/ssl/certs/ca-certificates.crt et suse-ldapsearch ne regarde RIEN. debian- Net::LDAP est à la recherche de /etc/ssl/certs/157753a5.? ( AddTrust_External_Root.pem ) et suse- Net::LDAP ne regarde RIEN.

Demandé el 31 de Octobre, 2011 par PrashantN

0 votes

Avatar de PrashantN

Pour info, le réglage verify='none' n'aide pas.

Commenté el 31 de Octobre, 2011 par PrashantN

Réponses

Trop de publicités?

1voto

jcollum avatar
jcollum Points 10236

Vous devez vérifier que le certificat SSL distant a la partie "CN" du sujet identique au nom d'hôte du serveur LDAPS dans vos commandes (ad.unsw.edu.au).

Pour voir l'utilisation du certificat distant :

echo ""|openssl s_client -connect ad.unsw.edu.au:636 |openssl x509 -noout -subject -dates -issuer

Tous les détails :

echo ""|openssl s_client -connect ad.unsw.edu.au:636 |openssl x509 -noout -text

Vérifiez que le certificat racine de l'émetteur est importé et approuvé dans l'annuaire ldap (cf. OpenLDAP SSL ) et le keystore SSL de perl (cf. IO::Socket::SSL ). S'il s'agit d'un certificat d'auto-signature, ce certificat doit être ajouté au trousseau de clés SSL de confiance.

Répondu el 31 de Octobre, 2011 par jcollum (10236 Points )

1 votes

Avatar de Janne Pikkarainen

Des chemins intéressants pour le client openssl, considérant que @Jayen semble avoir un environnement Linux. Je peux voir que votre Solaris-Fu est fort :-)

Commenté el 31 de Octobre, 2011 par Janne Pikkarainen

0 votes

Avatar de jcollum

Oui :). J'ai l'impression que le /usr/sfw est absent de Linux. Je vais modifier ma réponse.

Commenté el 31 de Octobre, 2011 par jcollum

0 votes

Avatar de PrashantN

Yup : echo -n | openssl s_client -connect ad.unsw.edu.au:636 | openssl verify -CAfile /tmp/COMODOHigh-AssuranceSecureServerCA.crt Merci !

Commenté el 31 de Octobre, 2011 par PrashantN
Afficher 3 autres commentaires

1voto

Thomas Maas avatar
Thomas Maas Points 1185

Net::LDAP::start_tls() est cassé dans perl-ldap-0.43. Votre ligne de commande devrait fonctionner correctement si vous mettez à jour vers 0.44 ou plus. Ceci est documenté dans le fichier Changes :

http://cpansearch.perl.org/src/MARSCHAP/perl-ldap-0.44/Changes

Bug Fixes
 * un-break certificate verification
Répondu el 17 de Février, 2012 par Thomas Maas (1185 Points )

0 votes

Avatar de PrashantN

Merci pour cela. J'ai trouvé un correctif dans github, et je me demande pourquoi ils n'ont pas sorti la 0.44 plus tôt. github.com/perl-ldap/perl-ldap/pull/3

Commenté el 18 de Février, 2012 par PrashantN

0voto

PrashantN avatar
PrashantN Points 1

Ligne 233 du Net/LDAP.pm sur Net::LDAP 0,43 dit

SSL_verifycn_scheme => "ldap",

debian wheezy utilise la 0.40, mais la mise à jour vers la 0.43 depuis unstable la casse également.

https://rt.cpan.org/Public/Bug/Display.html?id=70795

Répondu el 1 de Novembre, 2011 par PrashantN (1 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X