On January 27, 2021 10:43:48 PM UTC, Christopher Schultz <ch...@christopherschultz.net> wrote: >All, > >The Mapper seems to understand that case should be ignored while >looking >for hosts. That's expected, since it would have made Tomcat fail for >all >kinds of reasons in the past. > >However, the Mapper doesn't normalize. Instead, it performs >case-insensitive matching every time. I wonder if that couldn't be >improved by normalizing everything first and then executing a "normal" >match. Obviously, this is not critical. > >I'm not familiar enough with the TLS handshaking code in Tomcat to know > >where to start, but I've been looking at Connector, SSLHostConfig, >SSLHostConfigCertificate, etc. and I haven't found anything, yet. > >I'm fairly sure the code for choosing the certificate is actually in >JSSE.
Nope. We do it because JSSE doesn't support server side SNI. Once we hand the key store and socket over to JSSE, it picks >everything. But surely there is no such case-sensitivity bug in JSSE, >right? As per my previous mail, I strongly suspect a Tomcat bug. Start at TLSClientHelloExtractor and where the SNI name is then used in AbstractEndpoint with the sslHostConfigs Map. Mark > >-chris > >On 1/27/21 17:25, Christopher Schultz wrote: >> Daniel, >> >> On 1/27/21 15:37, Daniel Skiles wrote: >>> The tomcat instance is not on linux so I was not able to get >telnet/nc >>> up and running. >> >> Telnet should be available everywhere. Actually, only on Windows >these >> days lol. >> >>> That said, I do have information from both curl and java's keytool >>> -ssl server command. >> That should work. Also openssl s_client if you have that handy. >> >>> For keytool -ssl server, requesting HOST.domain.com >>> <http://HOST.domain.com> returns the correct certificate. If I >>> request host.domain.com <http://host.domain.com>, however, I get the > >>> certificate defined by the default host config. >> >> Curious: what is "keytool -ssl server"? >> >>> For curl, requesting HOST.domain.com <http://HOST.domain.com> >returns >>> the correct certificate. If I request host.domain.com >>> <http://host.domain.com>, however, I get the certificate defined by >>> the default host config. >>> >>> Is this a bug? >> >> That seems to point to Tomcat, then. >> >> We'll have a look. >> >> You are receiving the "wrong" cert in Chrome because it's normalizing > >> the hostname before connecting, which is appropriate. It appears that > >> curl sends the hostname as-is (good boy, curl!). >> >> -chris >> >>> On Wed, Jan 27, 2021 at 2:42 PM Christopher Schultz >>> <ch...@christopherschultz.net <mailto:ch...@christopherschultz.net>> > >>> wrote: >>> >>> Daniel, >>> >>> On 1/27/21 14:37, Daniel Skiles wrote: >>> > I'm currently running into some peculiar behavior with SNI, >and >>> I'm >>> > wondering if any of you might be able to offer suggestions. >I'm >>> not sure >>> > if it's a bad config, a bug, or a limitation of the software. >>> > >>> > I have a Tomcat instance that has two SSLHostConfig elements >>> applied. >>> > >>> > The first is the default SSLHostConfig. >>> > >>> > The second SSLHostConfig has a hostName of HOST.domain.com >>> <http://HOST.domain.com>. The >>> > Certificate entry for this SSLHostConfig contains a >certificate >>> that has >>> > HOST.domain.com <http://HOST.domain.com> in its SAN field. >>> > >>> > When I open Chrome and try to load https://HOST.domain.com/ >>> <https://HOST.domain.com/>, the request >>> > that goes across the wire is for https://host.docfinity.com >>> <https://host.docfinity.com>. I immediately >>> > receive a security warning from Chrome, and when I look at >the >>> certificate >>> > that's returned, it's the certificate for the default host >config. >>> > >>> > Are SSLHostConfig.hostName attribute values case sensitive in >>> Tomcat? I >>> > have looked through the documentation and it does not seem to > >>> specify >>> > either way. >>> >>> Hostnames are, by RFC[1] definition, NOT case-sensitive. Those >values >>> might be case-sensitive in Tomcat, though only accidentally. >>> >>> Can you confirm a few things: >>> >>> Using curl -v with HOST do you get the right cert? >>> >>> Using telnet/nc with HOST do you get the right cert? >>> >>> -chris >>> >>> [1] https://tools.ietf.org/html/rfc4343 >>> <https://tools.ietf.org/html/rfc4343> >>> > >--------------------------------------------------------------------- >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
