Gilles Chehade wrote, On 06/19/14 03:31:
On Thu, Jun 19, 2014 at 02:43:14AM -0700, Clint Pachl wrote:
yup, client certificate validation is output in the headers and will let
you known if the client has not presented a cert, presented a cert which
couldn't be verified/failed/succeeded.
Well that's awesome! Thanks Gilles.
I guess it's optional by default and `listen on tls-require verify` makes
client certificates mandatory, right?
right
What is the use-case of the client cert if the client is already supplying
valid authentication credentials (user/pass)?
The cert verification happens at the transport level, not the SMTP level
and an invalid certificate will cause TLS to abort and close connection.
You can use this for example to have your local CA issue certificates to
a set of internal machines and have the mail gateway accept relaying for
these machines without authentication.
You can also use this to ensure that users have a two-factor auth, their
credentials no longer are enough to relay, they would also have to use a
valid certificate issued by your CA. if their credentials are stolen, it
will not allow people to use the server as a spamming center.
Or you could decide to authenticate users using certificates and not the
traditional user/password mechanism. A client will then have to show you
a valid certificate otherwise connection will drop at TLS negotiation.
These are just few examples on the top of my head, I guess everyone with
a little imagination will find other interesting use-cases.
Great examples! Especially the two-factor one; I was actually wondering
about that possibility.
I guess I fail to see the benefit of client-to-server certificate
verification, sas opposed to mta-to-mta.
There is no such thing as a client-to-server vs mta-to-mta as far as the
SMTP protocol is concerned. A client and a MTA use the same protocol and
a MTA can't really distinguish between a client and another MTA.
What I meant is, I wasn't seeing the benefit of verification at the TLS
level for the server to verify the client, email or MTA clients.
However, when one MTA server is sending mail to another MTA, I
definitely see the benefit in verifying that receiving MTA before
sending mail to it. It's kind of like, before sending a request to
www.secure-bank.com, you want to verify it's certificate.
However, I do see the benefit of verifying the client, now that you
explained it so well. Breaking it into transport layer vs application
(SMTP) layer made it clear for me.
Can client certs somehow be used in lieu of user/pass credentials? I don't
see a way to store trusted client certs on the server. What am I missing?
Yes clients can be used instead of user/pass credentials.
As of now, it can only be done one way:
You setup a local CA and issue per-client certificates then you use your
CA to verify them. A client connecting with no certificate or one that's
not issued by your CA will have its connection dropped.
Aaha! That is awesome. I'm going to try this and see if I can get rid of
my passwords database.
I guess the first place I need to start is with the `pki hostname ca
cafile` directive, right?
What is this the minimum needed to configure this? How do you specify
the CA for client cert verification? Like this:
pki mail.example.com key "/etc/ssl/private/mail.example.com.key"
# used for server verification by client
pki mail.example.com certificate "/etc/ssl/mail.example.com.crt"
# used for client verification by server
pki mail.example.com ca "/etc/ssl/local.ca"
# enforce client certificates
listen on port submission tls-require verify pki mail.example.com
# does `relay` directive need anything special?
We can technically support authenticating clients using certificates not
issued by your CA if we introduced a new kind of table lookups where the
client certificate is looked up in a store. It's trivial work that could
be wrapped within a couple hours but no one expressed interest in it. It
is therefore not ranged high in my priority list.
It seems setting up a local CA probably covers 99% of most people's
needs, if they even go this route. However, this would be a cool feature.
Thanks again Gilles for this amazing software and support.
--
You received this mail because you are subscribed to [email protected]
To unsubscribe, send a mail to: [email protected]
