RE: Verifying 'CN' in client certificates using TLS

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Steve Powers [mailto:sgp@pani.cx]

> On Wed, Feb 06, 2002 at 03:05:14AM -0800, Howard Chu wrote:
>
> > Pretty much. Remember that in TLS, client certificates are
> always optional.
> > When you turn on TLSVerifyClient, the only thing that the library cares
> > about is that all of the signing CAs are recognized/trusted, and the
> > signatures are correct.

(Just to clarify what I said above - client certs are optional in the TLS
protocol spec. When you turn on TLSVerifyClient in slapd, then slapd
requires
client certs to be used.)

> > I don't understand what you're trying to test or
> > protect against.
>
> I am trying to move away from the use of IP based ACL's as much
> as possible,
> and therefore trying to ensure that the client certs being presented are
> from the correct source - As this is my only ultimate trust on
> the client/host.
> I realise this is still open to DNS and IP spoofing if a cert is
> compromised
> but I intent to add extra layers around this that make admin on the LDAP
> side just a little easier. <I hope>

The OpenSSL library supports a callback function that can be used to augment
the normal verification process. OpenLDAP doesn't do much with this callback
other than print debug traces. You could always patch your slapd to use a
more extensive check, extracting the CN, looking up the DNS info and failing
the connection if things don't match. It seems to me that you're really not
buying much security from doing this work. After all, the client cert can
only be used by someone who possesses the matching private key. If your
clients' private keys are already vulnerable enough that they can be
compromised, then DNS/IP spoofing is irrelevant.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support