Howard,

I'm building a framework for application servers, one generic task is
to setup ldap servers for user authentication and SSO with kerberos.

There will be situations where an ldap server will have a cert that
our server can't verify. In that case we'd like to ask the user if
they want to trust the cert on a permanent basis. To  do that we were
hoping to parse the cert from an s_client call. We can do this now for
ldaps (with openssl s_client -connect x.x.x.x:636 < /dev/null) , but
starttls is a problem.

Obviously we can work round this and allow users to install certs
before configuring ldap, but it would be smoother to allow it to
import the cert automatically.

Thanks,

John.




2009/6/4 Howard Chu <[email protected]>:
> John Carter wrote:
>>
>> Thanks Howard, but the problem we found with that was that the cert is
>> dumped in what looks like DER format mixed in with lots of other
>> binary data. However we also go nothing beyond doing -d 3.
>>
>> On the offchance your version of ldap is newer and dumps the certs
>> nicely, what version of ldap have you got?
>
> Nope, that's what all versions of OpenLDAP do. It also prints the cert
> subject DNs, that's been enough for most debugging purposes:
>
>  0730:  3a 54 c2 b5 f4 b0 37 29  d0 12 38 ae f0 0c cc 16   :T....7)..8.....
>  0740:  ba 9d 72 59 be c7 f7 81  39 70 55 e9 37 08         ..rY....9pU.7.
> TLS certificate verification: depth: 1, err: 0, subject:
> /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas
> Keymaster/[email protected], issuer:
> /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas
> Keymaster/[email protected]
> TLS certificate verification: depth: 0, err: 0, subject:
> /C=US/ST=California/L=Los Angeles/O=Symas Corp./OU=R&D/CN=violino.symas.net,
> issuer: /C=US/ST=California/L=Los Angeles/O=Symas Corp./CN=Symas
> Keymaster/[email protected]
> TLS trace: SSL_connect:SSLv3 read server certificate A
> tls_read: want=5, got=5
>  0000:  16 03 01 00 9f
>
> You haven't really explained enough of what you actually want to do yet, to
> give anyone a clear idea of what you're really asking for.
>
>> Thanks again,
>>
>> John.
>>
>>
>> 2009/6/4 Howard Chu<[email protected]>:
>>>
>>> John Carter wrote:
>>>>
>>>> Howard,
>>>>
>>>> I appreciate that currently the s_client code is plain-text, this
>>>> would have to change to support ASN.1.
>>>>
>>>> As you indicate "working" ldap once starttls done is hard/insane, but
>>>> as with all protocols that's the user's problem. Actually we are
>>>> primarily interested in seeing the certificate, rather than doing
>>>> anything useful with the connection.
>>>
>>> try "ldapsearch -ZZ -d7" ...
>>>
>>>> I'll see if anyone's interested.
>>>>
>>>> John.
>>>>
>>>> 2009/6/3 Howard Chu<[email protected]>:
>>>>>
>>>>> John Carter wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Currently the s_client command supports starttls for smtp, ftp etc.
>>>>>> We're wanting to do the same for ldap, something like:
>>>>>>
>>>>>> openssl s_client -connect 1.2.3.4:389 -starttls ldap
>>>>>>
>>>>>> We're willing to pay (around 200 USD) to have this feature added.
>>>>>>
>>>>>> Anyone interested?
>>>>>
>>>>> Just what do you expect s_client to be able to do once it's gotten this
>>>>> far?
>>>>> The s_client code only speaks plaintext; LDAP is ASN.1. You're not
>>>>> going
>>>>> to
>>>>> be able to type anything intelligible into s_client once it's done.
>>>>>
>>>>> And aside from that, the OpenLDAP libraries and tools already support
>>>>> StartTLS...
>>>>> --
>>>
>
> --
>  -- Howard Chu
>  CTO, Symas Corp.           http://www.symas.com
>  Director, Highland Sun     http://highlandsun.com/hyc/
>  Chief Architect, OpenLDAP  http://www.openldap.org/project/
> ______________________________________________________________________
> OpenSSL Project                                 http://www.openssl.org
> Development Mailing List                       [email protected]
> Automated List Manager                           [email protected]
>
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [email protected]

Reply via email to