The tomcat instance is not on linux so I was not able to get telnet/nc up and running. That said, I do have information from both curl and java's keytool -ssl server command.
For keytool -ssl server, requesting HOST.domain.com returns the correct certificate. If I request host.domain.com, however, I get the certificate defined by the default host config. For curl, requesting HOST.domain.com returns the correct certificate. If I request host.domain.com, however, I get the certificate defined by the default host config. Is this a bug? On Wed, Jan 27, 2021 at 2:42 PM Christopher Schultz < 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. The > > Certificate entry for this SSLHostConfig contains a certificate that has > > HOST.domain.com in its SAN field. > > > > When I open Chrome and try to load https://HOST.domain.com/, the request > > that goes across the wire is for 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 >
