Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Mark Thomas]

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
  returns the correct certificate.  If I
 request 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  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?
>>>
>>> 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
 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
 .  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

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Mark Thomas]

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  wrote:
> 
>> On 27/01/2021 19:42, Christopher Schultz wrote:
>>> On 1/27/21 14:37, Daniel Skiles wrote:
>>
>> 
>>
 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-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

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Mark Thomas]

On January 27, 2021 10:43:48 PM UTC, Christopher Schultz 
 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 
>>>  returns the correct certificate.  If I 
>>> request 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 
>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?
>> 
>> 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 
>>> 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
>>>     .  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-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

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Daniel Skiles]

> 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 <
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
> >>  returns the correct certificate.  If I
> >> request 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  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?
> >
> > 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
> >> 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
> >> .  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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Christopher Schultz]

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 
 returns the correct certificate.  If I 
request 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  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?


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 
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
    .  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Christopher Schultz]

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 
 returns the correct certificate.  If I request 
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  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?


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 
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
.  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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Daniel Skiles]

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  wrote:

> On 27/01/2021 19:42, Christopher Schultz wrote:
> > On 1/27/21 14:37, Daniel Skiles wrote:
>
> 
>
> >> 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Daniel Skiles]

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
>

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Mark Thomas]

On 27/01/2021 19:42, Christopher Schultz wrote:
> On 1/27/21 14:37, Daniel Skiles wrote:



>> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Case Sensitivity with SSLHostConfig.hostName and SNI

[Christopher Schultz]

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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Case Sensitivity with SSLHostConfig.hostName and SNI

[Daniel Skiles]

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.