On 06/12/17 01:06, George S. wrote: > > > On 12/1/2017 8:44 AM, Mark Thomas wrote: >> On 01/12/17 14:57, Chris Cheshire wrote: >>> I see in the changelog for 8.5.24 >>> >>> 60762: Add the ability to make changes to the TLS configuration of a >>> connector at runtime without having to restart the Connector. (markt) > > What strikes me as odd is that SSL Certificates are still coupled to > connectors. It seems like certificates should be coupled to Hosts since > that's what SNI does. SNI removes the coupling between an IP and a > virtual host name. > > Pre-SNI, there was a logical reason to associate a certificate with a > connector. The fact that you could only have one certificate on one IP, > made the one-to-one correlation obvious. Now, with SNI, you can have > many SSL Certificates with one IP. However, Tomcat's continuation of > associating the SSL Certificate with the Connector, rather than the > virtual host it's associated with is cumbersome because now when I > configure a virtual host with an SSL certificate, I not only have to > configure the host, but also the connector. As a database person, I try > to follow the rule that the attributes should follow the entity. In this > case, the attributes (SSLHostConfig) are facts about the virtual host, > and not about the Connector (entity). > > I'd like to see the Connector iterate over the virtual hosts and pick up > the SSLHostConfig from there. Perhaps the SSLHostConfig should have an > optional attribute "ConnectorName" to identify which Connector (assuming > there are multiple) the SSLHostConfig should bind to for the case of > multi-homed machines. The "ConnectorName" attribute would be used in > multi-homed hosts to specify which (of several) connectors the > SSLHostConfig should bind to.
The relationship between virtual host, SSLHostConfig and Connector is a complex one. Various options were considered when implementing SNI. The solution you propose assumes that there is a 1-2-1 mapping between virtual host and SSLHostConfig. That is not always the case. The use of wildcard certificates and Subject Alternative Names (SAN) so a certificate can be used with multiple virtual hosts means that the mapping can be complex. The complex mapping, combined with a requirement to provide a smooth migration path for existing uses led to the current solution. (Note that we don't currently support multiple aliases for a SSLHostConfig - that is something that should be fairly easy to add if required.) Tweaks to the existing implementation to simplify some use cases are always possible and - assuming no impact on existing users - likely to be accepted. The more significant the change, the greater the impact to existing users and the less likely the change is to be accepted. > Since I'm on wish lists, I wish that the Host XML snippet could be > specified via a file in $CATALINA_BASE/conf/EngineName/Virtual.Host.Name > via a magic name like _HOST.xml, or the like. I run anywhere from > 600-2000 virtual hosts on a machine, and my current "work-around" is to > use the inclusion hack to bring in an external file with the defined > virtual hosts. Each virtual host with its own set of web applications? Automatic inclusion of hosts sounds doable but needs thinking through. I don't see any immediate gotchas but it is similar to automatic context deployment and there are a huge number of edge cases in that use case once you start thinking about it. Automatic inclusion at start-up but no automatic deployment while running would be a lot simpler to implement. Mark > > >>> >>> Does this mean we can now update SSL certificates without bouncing the >>> connector? >> Yes, via one of the following methods on the endpoint: >> >> reloadSslHostConfig(String hostName) >> reloadSslHostConfigs() >> >> If accessing this via JMX, they appear as operations on the ThreadPool >> objects. >> >> Mark >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
