You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Daniel Skiles <ds...@docfinity.com> on 2021/01/27 19:37:39 UTC
Case Sensitivity with SSLHostConfig.hostName and SNI
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.
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Mark Thomas <ma...@apache.org>.
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 <
> chris@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
>>>> <chris@christopherschultz.net <ma...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Daniel Skiles <ds...@docfinity.com>.
> 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.
On Wed, Jan 27, 2021 at 5:44 PM Christopher Schultz <
chris@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
> >> <chris@christopherschultz.net <ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Mark Thomas <ma...@apache.org>.
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
>>> <chris@christopherschultz.net <ma...@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-unsubscribe@tomcat.apache.org
>For additional commands, e-mail: users-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
>> <chris@christopherschultz.net <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
> <chris@christopherschultz.net <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Daniel Skiles <ds...@docfinity.com>.
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 <
chris@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
>
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Mark Thomas <ma...@apache.org>.
On 27/01/2021 21:06, Daniel Skiles wrote:
> https://tools.ietf.org/html/rfc5280#section-4.2.1.6
>
> RFC5280, at least, seems to suggest that SANs need not be case sensitive.
>
> "Note that while uppercase and lowercase letters are allowed in domain
> names, no significance is attached to the case."
>
> There may be other implications that I have not uncovered. I am not
> intimately familiar with the Tomcat internals.
I was curious why the browser was converting to lower case and wondered
if there was an RFC requirement behind it but I haven't found one
either. I have found several references to comparing DNS names in a case
insensitive manner.
I'll work on updating Tomcat. The fix won't make the February releases
as they have already been tagged (unless the vote fails and we have to
re-tag). It should be in the March releases.
Mark
>
> On Wed, Jan 27, 2021 at 3:36 PM Mark Thomas <ma...@apache.org> wrote:
>
>> On 27/01/2021 19:42, Christopher Schultz wrote:
>>> On 1/27/21 14:37, Daniel Skiles wrote:
>>
>> <snip/>
>>
>>>> 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.
>>
>> Code inspection strongly suggests that is the case.
>>
>>> 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?
>>
>> Also need to check if there are any rules / specs for hosts names in
>> certs that require them to be lower case.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Daniel Skiles <ds...@docfinity.com>.
https://tools.ietf.org/html/rfc5280#section-4.2.1.6
RFC5280, at least, seems to suggest that SANs need not be case sensitive.
"Note that while uppercase and lowercase letters are allowed in domain
names, no significance is attached to the case."
There may be other implications that I have not uncovered. I am not
intimately familiar with the Tomcat internals.
On Wed, Jan 27, 2021 at 3:36 PM Mark Thomas <ma...@apache.org> wrote:
> On 27/01/2021 19:42, Christopher Schultz wrote:
> > On 1/27/21 14:37, Daniel Skiles wrote:
>
> <snip/>
>
> >> 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.
>
> Code inspection strongly suggests that is the case.
>
> > 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?
>
> Also need to check if there are any rules / specs for hosts names in
> certs that require them to be lower case.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Mark Thomas <ma...@apache.org>.
On 27/01/2021 19:42, Christopher Schultz wrote:
> On 1/27/21 14:37, Daniel Skiles wrote:
<snip/>
>> 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.
Code inspection strongly suggests that is the case.
> 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?
Also need to check if there are any rules / specs for hosts names in
certs that require them to be lower case.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Case Sensitivity with SSLHostConfig.hostName and SNI
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org