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. > 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. > 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. 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. -- Gilles Chehade https://www.poolp.org @poolpOrg -- You received this mail because you are subscribed to [email protected] To unsubscribe, send a mail to: [email protected]
