Show quoted text> > So in a client only 0 (no verification) and 1 (verify) make sense.
> OK, but then problem persists for 1 (verify), doesn't it ;-)
Sure, this was only a hint that the setting of 'verify' setting in
Net::LDAP probably behaves not like documented.
I guess 'optional' and 'required' will behave the same and both will fail
if the server does not send a certificate or if the certificate
or certificate chain is wrong.
Show quoted text> > From looking at the code of Net::LDAP the verification of the hostname
> > is tightly bound to the verification of the chain, e.g. in
> > _SSL_context_init_args the verification scheme gets set to ldap if
> > any kind of verification is wanted.
> Which - to me - sounds the right way to do for Net::LDAP that only deals
> with LDAP[IS] ;-)
Yes, IMHO it is the right way.
But then Net::LDAP must also know the name of the server, otherwise
it cannot verify it.
Show quoted text> ...
> Net::LDAP->start_tls()' sslerver parameter gets mapped to
> SSL_verifycn_name
> before calling IO::Socket::SSL->start_TLS, which internally uses PeerAddr
> and
> PeerHost as fallback if SSL_verifycn_name is not set.
> So it does not really matter which one is set exactly ;-)
No, it does matter.
PeerAddr is the name it connects to, which can be the name in the
certificate, but don't need to be.
If the user wants to connect to the ldap server using 'localhost'
or an IP address, but none of these are valid names in the certificate
the verification will fail - unless the user explicitly provided
a different server name using 'sslserver'.
But from the error message I think that problem in RT#77291 is before the
name verification. The name verification is done in IO::Socket::SSL,
but this is a message from OpenSSL, so there must be something other
be wrong with the certificate, before the name verification event
starts.
Do you have some way to reproduce the problem?
Show quoted text> If I understand you correctly, your recommendation is to special case
> Net::LDAP->start_tls() calls to localhost by determining & setting the real
> host name.
No, it's not only localhost, although this is probably a common case.
It's just the the user connects to a host and the host provides a certificate
not matching the name/IP from PeerAddr.
And my recommandation is not to add a special case in your code.
IMHO there is nothing you should do here except:
- document, that the name in the certificate will be verified
- document, how one can overwrite the name used for verification (e.g.
the sslserver setting)
- and maybe cleanup the documentation/behavior of the 'verify' option
If the user wants verification it should provide the necessary data,
otherwise we cannot claim to have the certificate verified.
Show quoted text> I was much more hoping for an additional verification scheme in
> IO::Socket::SSL, e.g. named 'ldap+localhost', that would do the the name
> checks, but accept localhost too ;-)
No, like I said - if the user wants verification he should get it.
What you propose its something magical "verify hostname unless the name
is localhost or an IP address or a known bad server or whatever...",
eg intransparently switch off verification in some circumstances even if
the user required verification.
Show quoted text> Maybe it even can try to find the FQDNs & IPs of the local host and match
> them against the certificate.
I doubt that you will be able to do it.
I often do ssh forwarding to some port at localhost - you probably will not
be able to figure out which real server is behind this localhost connection.
Regards,
Steffen
--
GeNUA Gesellschaft für Netzwerk - und Unix-Administration mbH
Domagkstr. 7, D-85551 Kirchheim.
http://www.genua.de
Tel: (089) 99 19 50-0, Fax: (089) 99 10 50 - 999
Geschäftsführer: Dr. Magnus Harlander, Dr. Michaela Harlander,
Bernhard Schneck. Amtsgericht München HRB 98238
