> On Apr 26, 2016, at 4:49 AM, Jeremy Harris <[email protected]> wrote: > > So much for encouraging people to actually use security.
One option is to generate a certificate on the fly at process startup if no default certificate is configured. Sure, SNI might sometimes lead to a different certificate, but if there's no exact match for SNI, the server should still return a default certificate: https://tools.ietf.org/html/rfc7672#section-8.1 If the server's TLSA records match the server's default certificate chain, the server need not support SNI. In either case, the server need not include the SNI extension in its TLS HELLO, as simply returning a matching certificate chain is sufficient. Servers MUST NOT enforce the use of SNI by clients, as the client may be using unauthenticated opportunistic TLS and may not expect any particular certificate from the server. If the client sends no SNI extension or sends an SNI extension for an unsupported domain, the server MUST simply send some fallback certificate chain of its choice. The reason for not enforcing strict matching of the requested SNI hostname is that DANE TLS clients are typically willing to accept multiple server names but can only send one name in the SNI extension. The server's fallback certificate may match a different name acceptable to the client, e.g., the original next-hop domain. With a default certificate in hand, STARTTLS never fails, and only clients that perform authentication might complain that the certificate did not match. The default certificate can be generated in a shell script that starts the server, or via C-code that generates a certificate in memory! (I can provide that if you like). Bottom-line, it is a good idea to enable TLS out of the box, but I think more care is best to make sure that STARTTLS is not advertised when it is sure to fail. -- Viktor. -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
