[Date Prev][Date Next]
RE: TLS client certs, SASL EXTERNAL
> -----Original Message-----
> From: Pierangelo Masarati [mailto:email@example.com]
> > 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 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
Symas: Premier OpenSource Development and Support