https://bz.apache.org/bugzilla/show_bug.cgi?id=57108
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> --- Proposed configuration vocabulary, which is backward-compatible with existing configurations: <Connector ... truststoreFile="..." (and other truststore attributes) keystoreFile="..." (and other keystore attributes) > <TLSAlias hostname="alternate.hostname" truststoreFile="..." (and other truststore attributes) keystoreFile="..." (and other keystore attributes) [other allowed configuration attributes] /> <TLSAlias hostname="alternate.hostname" truststoreFile="..." (and other truststore attributes) keystoreFile="..." (and other keystore attributes) [other allowed configuration attributes] /> </Connector> The TLS configuration attributes on the <Connector> will become the default TLS configuration for a request for a hostname that does not match any of the <TLSAlias> elements' hostname fields. Any request that exactly matches a hostname (or, perhaps we can do prefixing, globbing and/or regular expressions if people want to do that kind of thing) will instead use the TLS configuration of its matching <TLSAlias> element. There are some configuration elements that are appropriate to allow a <TLSAlias> element to override from the default. Proposed are all but those that appear in the following section. There are some attributes that should probably not be overridable in the <TLSAlias> elements, due their effect on all connections. Proposed attributes: SSLProtocol Care must be taken to ensure that subsequent handshakes -- for example, for the purposes of client re-negotiation or cipher-suite-switching -- do not allow a single client to switch from one hostname to another to, for instance, avoid some part of the authentication scheme or take advantage of a faulty configuration in host alias in order to "upgrade" to a different host with more stringent requirements. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org