[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: TLS client certs, SASL EXTERNAL



> -----Original Message-----
> From: Pierangelo Masarati [mailto:masarati@aero.polimi.it]
> > succeed. It seems to me that we need a middle "client cert is
> optional" state
> > in here, so that the server can ask for a client cert but will not
> complain if
> > none is available. Or we can just change the default state to
> "always ask for
> > optional client cert" for simplicity. Opinions, anyone?
>
> I'd prefer to have a third option (say "ASK", or "no" "yes" "critical"
> for consistency with the tls options), to allow more fine grain
> configuration.  I wonder what solution breaks the least number
> of installations :)

OK, I agree with that. I'm actually looking at 4 options now:
	no/never - same as old default, the server never asks for a client cert.
	allow - server asks. If a bad cert is received, ignore it.
	try - server asks. If a bad cert is received, kill connection.
	demand - same as "yes" - Must receive a valid cert.

In the "allow" and "try" cases, it is OK if the client has no cert. The
difference is just when a cert is presented. In the try case, if a bad cert is
received, fail the connection. In the allow case, if a bad cert is received,
just proceed as if no cert was received. This may be useful when a foreign
client has its own cert but the server doesn't recognize it; the normal
verification behavior would prevent the foreign client from ever using TLS with
the server.

The OpenSSL library directly supports the never/try/demand conditions. It will
take some tweaking in the callback routine to support the allow case.

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