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.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
