I noticed that Net::LDAP doesn't seem to correctly verify the SSL
certificate presented by a remote LDAP server, even if verify =>
'require' is given when creating a connection, as in:
my $ldap = new Net::LDAP(
version => 3,
verify => "require",
capath => "/etc/ssl/certs",
Specifically, Net::LDAP doesn't seem to attempt to verify the server's
identity -- as long as the server presents a certificate signed by a CA
that the client trusts, the client allows the connection to proceed.
This violates section 3.1.3 of RFC 4513, which describes how LDAP
clients should validate SSL certificates, and, IIUC, effectively allows
anyone with an SSL certificate for any site signed by a widely-trusted
CA to successfully impersonate, from the perspective of Net::LDAP
clients, any LDAP server, even if those clients are configured to
strictly validate server certificates.
This behavior seems to be a result of IO::Socket::SSL's default behavior
regarding identity verification, which is to not validate identities:
Set the scheme used to automatically verify the hostname of the
peer. See the information about the verification schemes in
verify_hostname. The default is undef, e.g. to not automatically
verify the hostname.
We can easily address this by changing the options we pass to
IO::Socket::SSL's new and start_SSL functions. I'm attaching a patch
that does this, setting SSL_verifycn_name to 'ldap'. This behaves
correctly in my tests: LDAPS connections to a server only succeed if the
server presents a certificate (signed by a CA trusted by the client)
that correctly identifies the name that the client connected to.
Any thoughts? Does this seem appropriate for inclusion in a future
release of the perl-ldap software?
Kevan Carstensen <kacarsten...@csupomona.edu>
Operating Systems Analyst, I&IT Systems, Cal Poly Pomona