On 27/01/2021 23:01, Daniel Skiles wrote: >> Curious: what is "keytool -ssl server"? > > https://docs.oracle.com/javase/7/docs/technotes/tools/solaris/keytool.html > > keytool -printcert has an additional -sslserver object, which will let you > connect to external servers and dump cert information. It's built into the > java distributions, so it was convenient to use.
Useful. I'd never seen that before. The case sensitive issue has been fixed in: - 10.0.x for 10.0.2 onwards - 9.0.x for 9.0.43 onwards - 8.5.x for 8.5.63 onwards Mark > > On Wed, Jan 27, 2021 at 5:44 PM 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. 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? >> >> -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
