| Table of Contents |
|---|
...
| Requirement for SNI approach | Details |
|---|---|
| Wildfly 15 or higher | WildFly 15 supports server side SNI on its HTTPS listeners. This allows a WildFly instance listening on a single socket but with multiple virtual hosts associated with that listener to provide a different server certificate depending on what SNI name the client requests. For Wildfly 15 SNI configuration, refer to Multi-exchange certificate, TLS and SAML support#SNI configuration in Wildfly 15 . |
| WebSphere 8.5 or higher | Websphere 8 seems supporting SNI with its own IBM SDK. For more information, please see: |
| Other Application servers | Not all application servers have built-in SNI support. In order to reap benefits from multiple exchange feature of CONNECT, adopters can employ Apache server. See section 696615044 for details. |
...
Multiple Certificate support with SNI
An assumption is made that CONNECT implementers participating in multiple exchanges will obtain separate SSL certificates for each exchange, thereby requiring the management of multiple private keys. This requires CONNECT to understand which private key to associate with which exchange. The certificate alias field in exchangeInfo.xml is used to load appropriate certificate for signing the SAML assertion. If there is no certificateAlias is defined in exchangeInfo.xml, CONNECT will pick the certificateAlias from system property CLIENT_KEY_ALIAS defined in server configuration.
...
| Anchor | ||||
|---|---|---|---|---|
|
Adopters, when limited by their application server platform, can use Apache (proxy) server and multiple ports (binding each exchange to a unique port) to implement multiple-exchange feature. Initiating gateway will send the SNI during SSL handshake. The SSL handshake will happen between Initiating gateway and Apache (proxy) server. Once the handshake is successful, Apache (proxy) server will direct the request to appropriate port based on the SNI sent in SSL handshake.
Setup Details for Wildfly-8.2.1
...