You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by James Lampert <ja...@touchtonecorp.com.INVALID> on 2024/12/20 04:15:39 UTC
Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
This afternoon, I was doing a routine certificate update for a
customer (cert in a Java Keystore), and when I restarted, Firefox
worked just fine with the site, but Chrome kept insisting it couldn't
negotiate a cipher.
The customer in question is still on Tomcat 7, because for some reason
(maybe having to do with the IBM Midrange box it's running on is
WAAayyyy behind on PTFs). I shut them down, swapped in the new
keystore (which I already had pre-staged), and I promptly discovered
that I'd used a different alias for the cert.
So I went into server.xml, found the connector, and removed the
keyAlias clause completely: after all, there's only one chain in the
keystore, and we've had plenty of connectors that work just fine with
no keyAlias clause.
This one didn't. It came back up, and it worked fine with Firefox and
Safari, but Chrome kept insisting that it couldn't negotiate a cipher.
I looked at it in SSLlabs, and everything looked just fine.
I switched it back to the old keystore, and Chrome still rejected it,
with the same claim.
Finally, I put the keyAlias clause back in, restarted, and it worked
just fine with Chrome. So I shut it back down, switched to the new
keystore, plugged the new alias into the keyAlias clause, and brought
it back up, and it still worked just fine.
I've added a note (in large, boldface, cranberry type) to the
customer's records, saying to always have a keyAlias clause, but I'm
still left with one nagging question:
What the <censored> just happened?
--
James H. H. Lampert
Touchtone Corporation
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 12/29/24 3:34 PM, Christopher Schultz wrote:
> Do you have a capture of the exact error? Handshake errors typically
> include at least a terse amount of detail.
On the client side, Chrome was singularly uninformative about the error.
With New Year's Eve and New Year's Day coming up, I might be able to run
the test again, and capture the exact browser message. If there's any
non-obvious place for me to look for underlying problems, please tell me.
I also looked at the catalina.out from the timeframe in which I ran my
test, and there is literally nothing in there between the message that
our webapp is up, and the message that I'd initiated a shutdown to
switch back to the "good" server.xml.
As a programmer, I have had to deal with customers who complain about
our terminal-based DB2/400-access utility crashing, but only giving us
the final error message issued by our product, while ignoring what could
be half a dozen or more joblog messages leading up to it, so I know
where you're coming from here. But at this point, I've tried to find
everything I'd be asking the customer to produce, and come up empty.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 1/5/25 1:36 PM, Pete Helgren wrote:
> Sounds a bit like what you are experiencing?
Perhaps. But only *just* a bit. Mainly in that Chrome is affected, but
Firefox and Safari aren't.
Remember: the problem *only* occurs when Tomcat is left to find the
chain on its own, without a keyAlias clause, and it *only* happens with
this one installation, on a box whose owners are unwilling to update
their OS or PTFs so it can at least run Tomcat 8 (which we've mostly
phased out in favor of 9). And I've left myself a note to always have a
keyAlias clause on that box.
I'm not particularly fast to fault them for not updating: my home
computers are a G4 "bionic desk lamp" iMac and a dual-boot tower built
from a motherboard old enough to support two separate physical floppy
drives, which runs IBM PC-DOS 2000 and can dual-boot to Ubuntu "Hardy
Heron" (but runs it so slowly that I rarely do so). And I just spent
over $500 having an antiquated color laser printer repaired, because
most newer ones wouldn't be on speaking terms with such an old iMac.
--
James H. H. Lampert
"Luddites of the World Unite: You have nothing to lose but your upgrade
treadmills!"
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Pete Helgren <pe...@valadd.com>.
James,
One more tidbit (perhaps you already saw this).
https://www.400power.com/node/323
Sounds a bit like what you are experiencing?
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
GIAC Cloud Penetration Tester
AWS Certified Cloud Practitioner
Microsoft Certified: Azure Fundamentals
On 1/2/2025 4:34 PM, Christopher Schultz wrote:
> James,
>
> On 1/2/25 2:45 PM, James H. H. Lampert wrote:
>> On 1/2/25 10:38 AM, Christopher Schultz wrote:
>>
>>> Is it possible that you are using a self-signed cert in this case?
>>> If you do not import the signed certificate properly into the
>>> keystore, you can end up with your private key+cert separate from
>>> the signed one from the CA.
>>>
>>> If you only have a single item in the keystore, that's not the issue
>>> but double-check the Issuer and Subject of the cert. They should be
>>> different if you are using a CA -- even if it's an internal CA like
>>> My-Company-CA or whatever.
>>>
>>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH really suggests Chrome doesn't
>>> like the TLS protocol version or can't match a cipher suite but that
>>> doesn't jive with your Qualys results. You are hitting this Tomcat
>>> instance directly, right? Not through a proxy or anything that might
>>> be performing its own TLS handshake that isn't Tomcat?
>>
>> None of these possibilities explain why Firefox and Qualys/SSLLabs
>> found nothing amiss.
>
> Yeah, this was why I was asking if maybe there was a load-balancer in
> the mix somewhere making everything "work" but I guess... not work. In
> retrospect, it was a dumb question :)
>
>> And the keystore appears to be just fine: just one chain, with the CA
>> reply imported properly into the subject cert, and the supporting
>> certs chained but not imported.
>
> There is no difference between chained and imported. If they are in
> the keystore (and are chained) then they are used. If not, then they
> obviously can't be used. "Import" just means putting the item into the
> keystore.
>
>> And yes, the Tomcat instance is being accessed directly.
>>
>> It wouldn't be the first time I've seen things I can't explain. And
>> they are the only customer installation that hasn't been migrated to
>> *at least* Tomcat 8, and I put a note about the anomaly in their
>> records.
> Well, I'm happy it's working for you under at least one configuration.
> Migrating forward to Tomcat 9 should obviously be on their schedule.
> I'm not sure what market sector they are in, but it's possible they
> are violating a required best practice, here: you shouldn't be running
> unsupported software. That said, there is at least one company I know
> of that will provide support for Tomcat 7 including back-porting all
> security fixes, etc. if your customer (or you, since you are the
> software provider) needs such paid support.
>
> -chris
>
>
> ---------------------------------------------------------------------
> 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: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 1/2/25 2:45 PM, James H. H. Lampert wrote:
> On 1/2/25 10:38 AM, Christopher Schultz wrote:
>
>> Is it possible that you are using a self-signed cert in this case? If
>> you do not import the signed certificate properly into the keystore,
>> you can end up with your private key+cert separate from the signed one
>> from the CA.
>>
>> If you only have a single item in the keystore, that's not the issue
>> but double-check the Issuer and Subject of the cert. They should be
>> different if you are using a CA -- even if it's an internal CA like
>> My-Company-CA or whatever.
>>
>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH really suggests Chrome doesn't like
>> the TLS protocol version or can't match a cipher suite but that
>> doesn't jive with your Qualys results. You are hitting this Tomcat
>> instance directly, right? Not through a proxy or anything that might
>> be performing its own TLS handshake that isn't Tomcat?
>
> None of these possibilities explain why Firefox and Qualys/SSLLabs found
> nothing amiss.
Yeah, this was why I was asking if maybe there was a load-balancer in
the mix somewhere making everything "work" but I guess... not work. In
retrospect, it was a dumb question :)
> And the keystore appears to be just fine: just one chain,
> with the CA reply imported properly into the subject cert, and the
> supporting certs chained but not imported.
There is no difference between chained and imported. If they are in the
keystore (and are chained) then they are used. If not, then they
obviously can't be used. "Import" just means putting the item into the
keystore.
> And yes, the Tomcat instance is being accessed directly.
>
> It wouldn't be the first time I've seen things I can't explain. And they
> are the only customer installation that hasn't been migrated to *at
> least* Tomcat 8, and I put a note about the anomaly in their records.
Well, I'm happy it's working for you under at least one configuration.
Migrating forward to Tomcat 9 should obviously be on their schedule. I'm
not sure what market sector they are in, but it's possible they are
violating a required best practice, here: you shouldn't be running
unsupported software. That said, there is at least one company I know of
that will provide support for Tomcat 7 including back-porting all
security fixes, etc. if your customer (or you, since you are the
software provider) needs such paid support.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 1/2/25 10:38 AM, Christopher Schultz wrote:
> Is it possible that you are using a self-signed cert in this case? If
> you do not import the signed certificate properly into the keystore, you
> can end up with your private key+cert separate from the signed one from
> the CA.
>
> If you only have a single item in the keystore, that's not the issue but
> double-check the Issuer and Subject of the cert. They should be
> different if you are using a CA -- even if it's an internal CA like
> My-Company-CA or whatever.
>
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH really suggests Chrome doesn't like
> the TLS protocol version or can't match a cipher suite but that doesn't
> jive with your Qualys results. You are hitting this Tomcat instance
> directly, right? Not through a proxy or anything that might be
> performing its own TLS handshake that isn't Tomcat?
None of these possibilities explain why Firefox and Qualys/SSLLabs found
nothing amiss. And the keystore appears to be just fine: just one chain,
with the CA reply imported properly into the subject cert, and the
supporting certs chained but not imported.
And yes, the Tomcat instance is being accessed directly.
It wouldn't be the first time I've seen things I can't explain. And they
are the only customer installation that hasn't been migrated to *at
least* Tomcat 8, and I put a note about the anomaly in their records.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 1/1/25 3:10 PM, James H. H. Lampert wrote:
> On 12/29/24 3:34 PM, Christopher Schultz wrote:
>> Do you have a capture of the exact error? Handshake errors typically
>> include at least a terse amount of detail.
>
>
> Here is what I get, after clicking the "details" button
> :
> <Sad document icon>
>> This site can’t provide a secure connection
>> <REDACTED>.com uses an unsupported protocol.
>> ERR_SSL_VERSION_OR_CIPHER_MISMATCH
> <Hide details button>
>> Unsupported protocol
>> The client and server don't support a common SSL protocol version or
>> cipher suite.
>
> The "Security Overview" in developer tools simply says, "This is an
> error page."
Is it possible that you are using a self-signed cert in this case? If
you do not import the signed certificate properly into the keystore, you
can end up with your private key+cert separate from the signed one from
the CA.
If you only have a single item in the keystore, that's not the issue but
double-check the Issuer and Subject of the cert. They should be
different if you are using a CA -- even if it's an internal CA like
My-Company-CA or whatever.
ERR_SSL_VERSION_OR_CIPHER_MISMATCH really suggests Chrome doesn't like
the TLS protocol version or can't match a cipher suite but that doesn't
jive with your Qualys results. You are hitting this Tomcat instance
directly, right? Not through a proxy or anything that might be
performing its own TLS handshake that isn't Tomcat?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 12/29/24 3:34 PM, Christopher Schultz wrote:
> Do you have a capture of the exact error? Handshake errors typically
> include at least a terse amount of detail.
Here is what I get, after clicking the "details" button
:
<Sad document icon>
> This site can’t provide a secure connection
> <REDACTED>.com uses an unsupported protocol.
> ERR_SSL_VERSION_OR_CIPHER_MISMATCH
<Hide details button>
> Unsupported protocol
> The client and server don't support a common SSL protocol version or cipher suite.
The "Security Overview" in developer tools simply says, "This is an
error page."
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 12/29/24 2:30 PM, James H. H. Lampert wrote:
> Testing with the "bad" configuration (i.e., no keyAlias clause), Firefox
> still reports "DLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS
> 1.2" and Chrome still rejects the site outright.
Do you have a capture of the exact error? Handshake errors typically
include at least a terse amount of detail.
> And the relevant sections of an SSLLabs scan, so far as I can determine,
> look *exactly like the sections I saved as a PDF Friday (and I saved the
> relevant sections as a PDF because that was the easiest way to visually
> compare the saved report to the live one).
>
> The only difference I can see is that unlike other customer
> installations that are on either Tomcat 8 or Tomcat 9, and work just
> fine without the keyAlias clause, this one installation is on Tomcat 7,
> because the OS version, available Java versions, and PTF level (of both
> the OS and the Java) don't get along well with Tomcat 8, and aren't
> expected to get along at all with Tomcat 9.
>
> It makes no sense to me.
The keyAlias should only be necessary if there are multiple entries in
your keystore. If you have exactly one "PrivateKeyEntry" in your key
store then it shouldn't matter at all.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
Testing with the "bad" configuration (i.e., no keyAlias clause), Firefox
still reports "DLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS
1.2" and Chrome still rejects the site outright.
And the relevant sections of an SSLLabs scan, so far as I can determine,
look *exactly like the sections I saved as a PDF Friday (and I saved the
relevant sections as a PDF because that was the easiest way to visually
compare the saved report to the live one).
The only difference I can see is that unlike other customer
installations that are on either Tomcat 8 or Tomcat 9, and work just
fine without the keyAlias clause, this one installation is on Tomcat 7,
because the OS version, available Java versions, and PTF level (of both
the OS and the Java) don't get along well with Tomcat 8, and aren't
expected to get along at all with Tomcat 9.
It makes no sense to me.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
Rob,
On 12/27/24 2:31 PM, Rob Sargent wrote:
>>
>> I've saved a PDF of the relevant part of the SSLLabs report, so that I can compare it if I'm able to try the other configuration on Sunday.
>>
>> --
>> JHHL
>>
>
> And you chose pdf over plain text why?
It's maybe easier for James to print-to-PDF than to
save-to-a-folder-of-random-web-assets and then have to find the primary
HTML file in that folder to open it and look at it? And then do all that
a second some, then compare?
Sure, copy/paste into a text editor might work for you and me, but if
you aren't absolutely sure what is and is not relevant, wouldn't you
want to have everything saved "just in case"?
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Rob Sargent <rs...@xmission.com>.
>
> I've saved a PDF of the relevant part of the SSLLabs report, so that I can compare it if I'm able to try the other configuration on Sunday.
>
> --
> JHHL
>
And you chose pdf over plain text why?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 12/27/24 11:35 AM, James H. H. Lampert wrote:
> On 12/27/24 8:14 AM, Christopher Schultz wrote:
>
>> When you got Chrome working again, which cipher suite did it
>> successfully negotiate? If you try in this configuration with Firefox,
>> which cipher suite is successfully negotiated?
>
> Dear Christopher:
>
> At this time, switching them back to the "no keyAlias clause"
> configuration is a non-starter (maybe sometime Sunday).
Understood. Maybe in a private testing environment? You don't even need
an application deployed; just use default ROOT or even nothing. All you
care about are TLS handshakes.
> But with the working configuration, Firefox reports
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2" and
> Chrome reports "TLS 1.2, ECDHE_RSA with P-256 and AES_128_GCM." (which
> *sounds* like a dumbed-down restatement of the same thing).
When in doubt, look up the cipher suite to get the details:
https://ciphersuite.info/cs/TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256/
(for sure, from the cipher suite's name above)
vs
https://ciphersuite.info/cs/TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256/
(a guess, given that the P-256 is thrown in there).
The difference is that one of them uses RSA for authentication
(certificate signature) while the other one uses an Elliptic Curve
(curve P-256, the so-called 256-bit "NIST curve" that basically
everybody uses).
The other elements of the two cipher suites are indeed the same (ECDHE
for key exchange, 128-bit AES in GCM mode for bulk encryption, SHA-256
for message signatures).
Hmm. "ECDHE_RSA with P-256" is a little confusing to me. Google (search)
says that it means P-256 is being used for the ECDHE key exchange before
authentication. So P-256 was a red herring as far as I'm concerned
because typically you are more interested in how the authentication is
being done (RSA vs EC).
> Again, with the working configuration, SSLLabs reports:
>
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 128
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS
>> WEAK 128
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 128
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS 128
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 256
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS
>> WEAK 256
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 256
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS 256
That all looks pretty standard, though I see secp521r1 in there which is
NIST P-521 and not NIST P-256.
If you are curious about why some of those are listed as "weak", it's
because AES in CBC mode is vulnerable to certain types of attacks, so
every suite containing "CBC" will be marked as "weak" by Qualys. You can
read more about it here [1].
In spite of that warning, I would say that leaving the CBC-based cipher
suites enabled in your server is reasonable for a "standard paranoia
level" web site/service. If you are absolutely sure that all of your
clients are using modern software to access your site, you can dump the
CBC cipher suites entirely.
> I've saved a PDF of the relevant part of the SSLLabs report, so that I
> can compare it if I'm able to try the other configuration on Sunday.
Sounds good to me.
I'm assuming in both cases, you are using an RSA key with the same bit-count
-chris
[1]
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Cipher_block_chaining_(CBC)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 12/27/24 1:17 PM, Pete Helgren wrote:
> I haven't followed the full thread but are you using the HTTP Server for
> i as a front end and DCM to serve Certificates?
No; just running Tomcat (7.0 on that particular customer box, because
the OS release and PTF level won't support Tomcat 8, much less 9), with
the cert in a Java Keystore. Most customer boxes are either on 8 or 9;
ours, at least those exposed to the public, are on 9.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Pete Helgren <pe...@valadd.com>.
James,
I haven't followed the full thread but are you using the HTTP Server for
i as a front end and DCM to serve Certificates? A couple of years back,
I ran into an issue with the HTTP server when I was using both RSA and
ECDHE certs, at least using the HTTP Server for i as a reverse proxy.
So IBM support suggested I create all certificates using either RSA OR
ECDHE. I've been sticking with RSA, for now.
Clutching at straws a bit....
Pete Helgren
www.petesworkshop.com
GIAC Secure Software Programmer-Java
GIAC Cloud Penetration Tester
AWS Certified Cloud Practitioner
Microsoft Certified: Azure Fundamentals
On 12/27/2024 10:35 AM, James H. H. Lampert wrote:
> On 12/27/24 8:14 AM, Christopher Schultz wrote:
>
>> When you got Chrome working again, which cipher suite did it
>> successfully negotiate? If you try in this configuration with
>> Firefox, which cipher suite is successfully negotiated?
>
> Dear Christopher:
>
> At this time, switching them back to the "no keyAlias clause"
> configuration is a non-starter (maybe sometime Sunday).
>
> But with the working configuration, Firefox reports
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2" and
> Chrome reports "TLS 1.2, ECDHE_RSA with P-256 and AES_128_GCM." (which
> *sounds* like a dumbed-down restatement of the same thing).
>
> Again, with the working configuration, SSLLabs reports:
>
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 128
>> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS
>> WEAK 128
>> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 128
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS 128
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 256
>> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS
>> WEAK 256
>> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS WEAK 256
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq.
>> 15360 bits RSA) FS 256
>
> and
>
>> Android 4.4.2 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
>> Android 5.0.0 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDH secp521r1 FS
>> Android 6.0 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Android 7.0 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Android 8.0 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Android 8.1 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Android 9.0 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> BingPreview Jan 2015 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
>> Chrome 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Chrome 69 / Win 7 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Chrome 70 / Win 10 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Chrome 80 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Firefox 31.3.0 ESR / Win 7 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Firefox 47 / Win 7 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Firefox 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Firefox 62 / Win 7 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Firefox 73 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> Googlebot Feb 2018 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
>> IE 11 / Win 7 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> IE 11 / Win 8.1 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> IE 11 / Win Phone 8.1 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDH secp256r1 FS
>> IE 11 / Win Phone 8.1 Update R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> IE 11 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Edge 15 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Edge 16 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Edge 18 / Win 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Edge 13 / Win Phone 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Java 8u161 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Java 11.0.3 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Java 12.0.1 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> OpenSSL 1.0.1l R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
>> OpenSSL 1.0.2s R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> OpenSSL 1.1.0k R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> OpenSSL 1.1.1c R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 6 / iOS 6.0.1 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Safari 7 / iOS 7.1 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Safari 7 / OS X 10.9 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Safari 8 / iOS 8.4 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Safari 8 / OS X 10.10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
>> Safari 9 / iOS 9 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 9 / OS X 10.11 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 10 / iOS 10 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 10 / OS X 10.12 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 12.1.2 / MacOS 10.14.6 Beta R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Safari 12.1.1 / iOS 12.3.1 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Apple ATS 9 / iOS 9 R RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
>> Yahoo Slurp Jan 2015 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
>> YandexBot Jan 2015 RSA 2048 (SHA256) TLS 1.2
>> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
>
> I've saved a PDF of the relevant part of the SSLLabs report, so that I
> can compare it if I'm able to try the other configuration on Sunday.
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> 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: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com.INVALID>.
On 12/27/24 8:14 AM, Christopher Schultz wrote:
> When you got Chrome working again, which cipher suite did it
> successfully negotiate? If you try in this configuration with Firefox,
> which cipher suite is successfully negotiated?
Dear Christopher:
At this time, switching them back to the "no keyAlias clause"
configuration is a non-starter (maybe sometime Sunday).
But with the working configuration, Firefox reports
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, 128 bit keys, TLS 1.2" and
Chrome reports "TLS 1.2, ECDHE_RSA with P-256 and AES_128_GCM." (which
*sounds* like a dumbed-down restatement of the same thing).
Again, with the working configuration, SSLLabs reports:
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS WEAK 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67) DH 2048 bits FS WEAK 128
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e) DH 2048 bits FS 128
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 128
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) ECDH secp521r1 (eq. 15360 bits RSA) FS 128
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS WEAK 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256
> TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) DH 2048 bits FS WEAK 256
> TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f) DH 2048 bits FS 256
> TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp521r1 (eq. 15360 bits RSA) FS WEAK 256
> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030) ECDH secp521r1 (eq. 15360 bits RSA) FS 256
and
> Android 4.4.2 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
> Android 5.0.0 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA ECDH secp521r1 FS
> Android 6.0 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Android 7.0 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Android 8.0 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Android 8.1 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Android 9.0 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> BingPreview Jan 2015 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
> Chrome 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Chrome 69 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Chrome 70 / Win 10 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Chrome 80 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Firefox 31.3.0 ESR / Win 7 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Firefox 47 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Firefox 49 / XP SP3 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Firefox 62 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Firefox 73 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> Googlebot Feb 2018 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 ECDH secp256r1 FS
> IE 11 / Win 7 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> IE 11 / Win 8.1 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> IE 11 / Win Phone 8.1 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 ECDH secp256r1 FS
> IE 11 / Win Phone 8.1 Update R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> IE 11 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Edge 15 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Edge 16 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Edge 18 / Win 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Edge 13 / Win Phone 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Java 8u161 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Java 11.0.3 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Java 12.0.1 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> OpenSSL 1.0.1l R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
> OpenSSL 1.0.2s R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> OpenSSL 1.1.0k R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> OpenSSL 1.1.1c R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 6 / iOS 6.0.1 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Safari 7 / iOS 7.1 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Safari 7 / OS X 10.9 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Safari 8 / iOS 8.4 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Safari 8 / OS X 10.10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 ECDH secp256r1 FS
> Safari 9 / iOS 9 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 9 / OS X 10.11 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 10 / iOS 10 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 10 / OS X 10.12 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 12.1.2 / MacOS 10.14.6 Beta R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Safari 12.1.1 / iOS 12.3.1 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Apple ATS 9 / iOS 9 R RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp256r1 FS
> Yahoo Slurp Jan 2015 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp384r1 FS
> YandexBot Jan 2015 RSA 2048 (SHA256) TLS 1.2 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ECDH secp521r1 FS
I've saved a PDF of the relevant part of the SSLLabs report, so that I
can compare it if I'm able to try the other configuration on Sunday.
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Weirdest thing this afternoon: Firefox liked a server, but Chrome didn't
Posted by Christopher Schultz <ch...@christopherschultz.net>.
James,
On 12/19/24 11:15 PM, James Lampert wrote:
> This afternoon, I was doing a routine certificate update for a
> customer (cert in a Java Keystore), and when I restarted, Firefox
> worked just fine with the site, but Chrome kept insisting it couldn't
> negotiate a cipher.
What cipher suite did Firefox successfully negotiate?
> The customer in question is still on Tomcat 7, because for some reason
> (maybe having to do with the IBM Midrange box it's running on is
> WAAayyyy behind on PTFs). I shut them down, swapped in the new
> keystore (which I already had pre-staged), and I promptly discovered
> that I'd used a different alias for the cert.
>
> So I went into server.xml, found the connector, and removed the
> keyAlias clause completely: after all, there's only one chain in the
> keystore, and we've had plenty of connectors that work just fine with
> no keyAlias clause.
>
> This one didn't. It came back up, and it worked fine with Firefox and
> Safari, but Chrome kept insisting that it couldn't negotiate a cipher.
> I looked at it in SSLlabs, and everything looked just fine.
>
> I switched it back to the old keystore, and Chrome still rejected it,
> with the same claim.
>
> Finally, I put the keyAlias clause back in, restarted, and it worked
> just fine with Chrome. So I shut it back down, switched to the new
> keystore, plugged the new alias into the keyAlias clause, and brought
> it back up, and it still worked just fine.
When you got Chrome working again, which cipher suite did it
successfully negotiate? If you try in this configuration with Firefox,
which cipher suite is successfully negotiated?
What does SSLLabs say for each of the two configurations in terms of
supported cipher suites?
Do the keys used in both cases have similar qualities (e.g. key type
RSA-vs-EC, same bit count, and same-curve for EC)?
> I've added a note (in large, boldface, cranberry type) to the
> customer's records, saying to always have a keyAlias clause, but I'm
> still left with one nagging question:
>
> What the <censored> just happened?
Tomcat needs to select the right key and cert from the keystore so if
that's wrong things won't work. But the way you describe them
not-working is odd. Typically, if Tomcat can't find the key+cert, the
connector will simply fail to initialize and you won't be able to
connect to it AT ALL.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org