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
