SNI Support

This will involve adding a new server-sni-ssl-context resource to the Elytron subsystem. This resource will have a non-optional attribute named default-ssl-context that references an existing server-ssl-context.

In addition this resource has a host-context-map attribute, this maps names (which may be wildcard names) to server-ssl-context resources, and will be used by the SNI support to determine the correct context to choose. Wildcard names use * as a wildcard, and can only be used to match a single level of subdomain in much the same way as with wildcard certificates.

This server-sni-ssl-context will provide the same capabilities as server-ssl-context and should be able to be used anywhere that accepts a server-ssl-context (the exception to this is anything that requires a SSLSocket, but I don’t think we have any at present).

When a SSLEngine is created a wrapper engine will be created, and will attempt to parse any incoming client hello message to determine the correct underlying SSLContext to use. If no SNI information is present then the default will be used. Non wildcard names are matched before wildcard names.

Once the correct SSLContext has been selected it is used to create the correct SSLEngine, which then handles the connection as normal.

This must also work with ALPN to allow HTTP/2 to work. As such it must be possible to register some kind of callback to be invoked when the underlying engine is selected, in order to allow Undertow to perform its HTTP/2 integration.