On Thu 2018-03-22 14:49:18 -0400, Viktor Dukhovni wrote:
> https://tools.ietf.org/html/rfc7672#section-8.1
>
>
> [...] The
> server MAY rely on SNI to determine which certificate chain to
> present to the client. Clients that don't send SNI information may
> not see the expected certificate chain.
>
> 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.
for reference, Viktor is proposing this text for inclusion in the
MTA-STS draft, to ensure that servers are liberal about SNI -- it should
be up to the client to reject a failed authentication, not for the
server to pre-emptively abort.
--dkg
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
