On Tue, Feb 12, 2008 at 02:10:14PM -0800, Richard A Nelson wrote:
> On Tue, 12 Feb 2008, Andrew Reid wrote:
>
> >Package: libnss-ldap
> >Version: 258-1b+1
>
> This certainly appears to be an OpenSSL issue, not libnss-ldap
>
> > 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.
>
> Since the message deals with the peer certificate, you need
> to verify not the local cacert certificate - but the LDAP server
> certificate itself.
>
> Please try this on both releases:
> openssl s_client -connect <LDAP_SERVER_FQDN>:ldaps
Both systems do nearly the same thing, with only differences
that look irrelevant to me. I get:
> CONNECTED(00000003)
> depth=1 /C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards
> and Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> verify error:num=19:self signed certificate in certificate chain
> verify return:0
> ---
> Certificate chain
> 0 s:/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=shadrach.nist.gov
> i:/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> 1 s:/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> i:/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
... then the certificate itself, and then:
> -----END CERTIFICATE-----
> subject=/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards
> and Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=shadrach.nist.gov
> issuer=/C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> ---
> Acceptable client certificate CA names
> /C=US/ST=Maryland/L=Gaithersburg/O=National Institute of Standards and
> Technology/OU=Center for Theoretical and Computational Materials
> Science/CN=CTCMS
> ---
> SSL handshake has read 2596 bytes and written 328 bytes
> ---
> New, TLSv1/SSLv3, Cipher is AES256-SHA
> Server public key is 1024 bit
> Compression: NONE
> Expansion: NONE
> SSL-Session:
> Protocol : TLSv1
> Cipher : AES256-SHA
> Session-ID: <Data>
> Session-ID-ctx:
> Master-Key: <Data>
> Key-Arg : None
> Start Time: 1202854401
> Timeout : 300 (sec)
> Verify return code: 19 (self signed certificate in certificate chain)
> ---
The "<Data>" entries are long hexadecimal strings which differ
between the two platforms, and also between invocations on the
same platform -- evidently session-specific data, as indicated by
the header.
> > In any case, it seems clear to me that, at a minimum, the
> >certificate status is being misreported.
>
> Possibly, but we'll know more after the above tests
Hope this helps. Please feel free to make educational comments
about how SSL is supposed to work along the way.
-- 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]
