Package: libnss-ldap
Version: 258-1b+1
I have a group of hosts which use libnss-ldap for passwd and
shadow information, and have recently added a lenny client to
the group, which otherwise consists of etch machines.
All clients use ldaps/TLS to communicate with the slapd on the
server. The lenny client was initially configured identically
to the etch clients.
In particular, the nontrivial lines of /etc/libnss-ldap.conf are:
> base dc=<sanitized>,dc=<sanitized>
> uri ldaps://<fq hostname>/
> ldap_version 3
> bind_policy hard
> ssl on
> tls_checkpeer yes
> tls_cacertfile /etc/ldap/cacerts/cacert.pem
> use_sasl no
> rootuse_sasl no
> nss_initgroups_ignoreusers
> root,daemon,bin,sys,sync,man,lp,mail,nobody,statd,sshd,ntp
... and /etc/ldap/ldap.conf has:
> BASE dc=<sanitized>, dc=<sanitized>
> URI ldaps://<fq hostname>/
> TLS_CACERT /etc/ldap/cacerts/cacert.pem
> TLS_REQCERT hard
This configuration allows connections from an etch client to
the etch server, but not from a lenny client to the etch server,
with the same certificates in both cases.
Running "id <valid-username>" illustrates the difference
in behavior, on the etch client I get the username output,
and on the lenny client, I get "no such user".
Running "strace id <valid-username>" shows that the socket
connection is succeeding on the correct port, and reads and
writes through the socket are successful. This eliminates
networking issues.
Running "id <valid-username>" with a "debug 9999" line added
to /etc/libnss-ldap.conf gives a message part way through
stating "TLS: peer certificate is expired", but running
"openssl -x509 -text -in /etc/ldap/cacerts/cacert.pem" shows
that the certificate's validity period extends from October 2006
through October 2016. "date" on the lenny client gives the
correct date.
Doing the same "debug 9999" "id <valid-username>" operation
on an etch client shows a "certificate validated" message.
A work-around is to change the TLS-REQCERT entry in
/etc/ldap/ldap.conf to "allow", although presumably this means
that the traffic is then not encrypted. "try" and "hard"
both fail, and "never" also allows the "id" process to succeed.
The permissions on /etc/ldap/cacerts/cacert.pem are 644.
One oddity is that the certificate *is* self-signed. I have
seen documentation suggesting that this could be a problem, but
I'm unclear on whether this is really the case, and encouraged
by the fact that the etch clients don't appear to have a
problem with this.
My personal suspicion is that some security default has changed,
or possibly that I'm missing an optional library or cipher method
or something, and this is possibly a migration issue. I would
appreciate any assistance you could offer with that.
In any case, it seems clear to me that, at a minimum, the
certificate status is being misreported.
-- A.
--
Dr. Andrew C. E. Reid
Computer Operations Administrator
Center for Theoretical and Computational Materials Science
National Institute of Standards and Technology, Mail Stop 8910
Gaithersburg MD 20899 USA
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
