In message <56dfcd11.5010...@spectralmud.org> Richard James Salts writes: > On 09/03/16 06:44, Viktor Dukhovni wrote: > >> On Mar 8, 2016, at 2:31 PM, Curtis Villamizar <cur...@orleans.occnc.com> > >> wrote: > >> > >> With HTTP the server cert is provided after HTTP identifies which > >> virtual host it thinks its talking to. The IP address along gives no > >> clue. That connection is then used only for that virtual host. This > >> is why you can have a TLS cert per vhost (aka DNS domain). > > To be more precise, with HTTPS, the desired TLS server name is > > conveyed via the TLS SNI extension and the HTTP server presents > > the corresponding certificate. By contrast, the Postfix SMTP > > server neither supports nor needs SNI. > But some MUAs (i.e. user's mail clients) do support SNI and will try to > match against the name that was entered into the configuration. This > might be important if you have many white label resellers who want > clients to be able to enter mail.<reseller's domain> into their > customers mail clients.
Which MUAs and exactly how do they use SNI? Most MUAs would be talking to a IMAP to receive mail and might also use IMAP to send mail, therefore port 993, not 25 or 587. btw- I think Dovecot imapd supports SNI but Cyrus imapd does not, but I'm not sure about that. If any do use port 587 do the MUAs use SNI to indicate which sender domain? Your statement above seems to indicate a check made by the client, but against what? The CN or subjectAltName(s) in the cert? AFAIK postfix has no support for SNI other than the limited support for DANE, but a cert with MX FQDN in CN and all domains pointing at that MX in subjectAltName also solves this with or without SNI. There does not seem to be any postfix config option to specify per SNI cert. Did I miss it? Otherwise, the only solution is putting everything in subjectAltName (which means SNI does nothing for port 587 use). > > Firstly, SMTP TLS connections are typically unauthenticated, and > > it does not matter which certificate the server presents, so no > > need to have one that matches any particular name. > > > > In the rare cases that authentication does take place through > > the magic of MX record redirection a single MX host can support > > multiple domains provided that it is the MX hostname and not the > > target domain that the client authenticates. This is the case > > with DANE. > > > > https://tools.ietf.org/html/rfc7672#section-1.3 The original question I think had to do with port 587 TLS (though I admit some initial confusion on Tom's objectives) which would normally use smtpd_tls_req_ccert=yes and use smtpd_tls_security_level=encrypt on the server side. On the client side, connection to port 587 would be better off with smtp_tls_security_level=encrypt rather than dane-only and this would have nothing to do with MX records. In this context (no MX lookup at all) I'm not sure what role SNI would play (in a world where postfix supported everything even remotely useful). If the original question was related to outside users connecting via port 25 to send mail to a mailing list and getting a "per vhost cert" (Tom's words, approximately), then SNI could do something useful if postfix had a means to set smtpd_tls_key_file and smtpd_tls_cert_file per SNI. This could be supported if something existed that was like smtp_tls_policy_maps (the key feature being able to set any main.cf policy statememt in the rhs) but on the smptd_ side and using SNI as the key. (Maybe such a config option exists in a world where postfix supports everything even remotely useful, but I couldn't find it in local or online docs). This would work with or without TLSA records. If one MX supports a large number of domains, the subjectAltName could get rather large if there is no means to select key and cert based on SNI and if the client side wanted to verify per domain (as DANE does) rather than looking for the MX name in the cert. Just an observation. Did I go wrong here somewhere? Curtis
