Weird error with certificate chain (JSSE security, with a JKS, in 7.0.93)

["James H. H. Lampert" <ja...@touchtonecorp.com>]

We maintain a bunch of Tomcat 7 servers for various customers, all using 
JSSE security, with a JKS.

All of them show a complete certificate chain when accessed from a 
browser. Some (if TLSv1.2 is not enabled, and especially those running 
on boxes that don't have Java 7 or Java 8) get complaints about obsolete 
connection settings, but even they show complete chains.

For most of them, if I do an SSLLabs scan, SSLLabs shows (and indeed, 
complains about an "anchor present" in) a complete-down-to-root 
certificate chain. But for some of them, it says it has to go out and 
look for the intermediate cert.

I asked about it on the Qualsys board; they suggested I try
 > openssl s-client -showcerts -connect <domain:port>

I tried this for one of the ones for which SSLLabs claims it's getting 
an incomplete chain, and sure enough, I get (domain name changed to 
protect the innocent):

> depth=0 OU = Domain Control Validated, CN = frobozz.com
> verify error:num=20:unable to get local issuer certificate
> verify return:1
> depth=0 OU = Domain Control Validated, CN = frobozz.com
> verify error:num=21:unable to verify the first certificate
> verify return:1

Whereas, for one of the ones for which SSLLabs *only* complains that the 
chain "contains anchor," I get (all identifying fields changed to 
protect the innocent):

> depth=2 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for authorized use only", CN = Entrust Root Certification Authority - G2
> verify return:1
> depth=1 C = US, O = "Entrust, Inc.", OU = See www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for authorized use only", CN = Entrust Certification Authority - L1K
> verify return:1
> depth=0 C = GUE, ST = Quendor, L = Flatheadia, O = "Frobnitz, Inc.", CN = frobnitz.com
> verify return:1

I can't tell any difference in the keystore structure between the two, 
and browsers don't show anything amiss. Does anybody have any insights 
into why the keystores would behave differently in SSLLabs and "openssl 
s-client -showcerts"?

--
JHHL

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Weird error with certificate chain (JSSE security, with a JKS, in 7.0.93)

["James H. H. Lampert" <ja...@touchtonecorp.com>]

On 3/19/20 12:26 PM, Christopher Schultz wrote:
> In case(2) can you show us what certificates are present in your keystore?
> 
> Something like:
> 
> $ keytool -verbose -list -keystore server.jks

Dear Mr. Schultz, et al:

Actually, at least with the version of keytool I have, it would be more 
like:
"keytool -list -v -keystore frobozz.ks"

I was about to send (off-List, marked "CONFIDENTIAL") dumps of an 
"incomplete chain" keystore that nonetheless had all the certs it 
needed, and one that wasn't giving the error (as a control), when I 
spotted something in the dumps myself:

Problem:
> Your keystore contains 3 entries
> 
> Alias name: wintouch
> Creation date: Oct 15, 2019
> Entry type: PrivateKeyEntry
> Certificate chain length: 1
> Certificate[1]:


Control:
> Your keystore contains 3 entries
> 
> Alias name: wintouch
> Creation date: Apr 2, 2018
> Entry type: PrivateKeyEntry
> Certificate chain length: 3


I had earlier noticed that the alias for the intermediate cert was not 
the same as what the site cert cited as its signer, and so I had tried 
changing the alias (with no effect). (I generally use a product called 
KeyStore Explorer for everything but initial generation of the keystore, 
and found it had a "rename" function.)

I looked at both the "problem" and "control" keystores in KSE, and found 
that even though both keystores were "complete-to-root," if I pulled up 
the "certificate chain details" on them, the "control"  KS showed a 
complete-to-root chain, while the "problem" KS showed only the site cert.

So I tried re-importing the CA reply (in KSE), on the copy that had the 
renamed intermediate cert. No effect. So then I went back to the 
self-signed KS, and re-imported everything again, fixing the alias as I 
went along. Still no effect.

But in the process, I noticed a menu option I'd never noticed before: 
"Edit Certificate Chain." Which turned out to be a sub-menu with 
"Append" and "Remove" options. I tried the "Append" option, and BINGIE, 
it was showing the intermediate CA in the chain (at least in KSE).

As I type this, I just now squirted the latest iteration of the KS over 
to the customer's box, swapped it into place, and restarted Tomcat. Now, 
the SSLLabs report shows an "A" rating, with the intermediate in the 
chain. BINGIE!

--
JHHL

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org

Re: Weird error with certificate chain (JSSE security, with a JKS, in 7.0.93)

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

James,

On 3/19/20 12:24, James H. H. Lampert wrote:
> We maintain a bunch of Tomcat 7 servers for various customers, all
> using JSSE security, with a JKS.
>
> All of them show a complete certificate chain when accessed from a
> browser. Some (if TLSv1.2 is not enabled, and especially those
> running on boxes that don't have Java 7 or Java 8) get complaints
> about obsolete connection settings, but even they show complete
> chains.
>
> For most of them, if I do an SSLLabs scan, SSLLabs shows (and
> indeed, complains about an "anchor present" in) a
> complete-down-to-root certificate chain. But for some of them, it
> says it has to go out and look for the intermediate cert.

It has to go looking for the intermediate cert, or for the root?
Generally, you don't provide the root because the client should
already have that one.

A typical arrangement is that a Certificate Authority (CA) has a root
certificate and one or more intermediate certs, and the intermediate
certs are used to sign the server certs (that's your certificate: the
"server" cert).

So it looks like this:

CA Root certificate
 |
 \/
Intermediate certificate
 |
 \/
Server certificate

Your server should provide the server and intermediate certs to
clients, but not the root.

Having the server certificate, it's often not possible to figure out
where to get the intermediate certificate. The identity of the signer
is embedded in the server certificate, but not the location of the
signer's public certificate should it be necessary.

I'd be interested to see the SSL Labs report on the server saying it
had to "go out and look" for the intermediate certificate.

> I asked about it on the Qualsys board; they suggested I try
>> openssl s-client -showcerts -connect <domain:port>
>
> I tried this for one of the ones for which SSLLabs claims it's
> getting an incomplete chain, and sure enough, I get (domain name
> changed to protect the innocent):
>
>> depth=0 OU = Domain Control Validated, CN = frobozz.com verify
>> error:num=20:unable to get local issuer certificate verify
>> return:1 depth=0 OU = Domain Control Validated, CN = frobozz.com
>> verify error:num=21:unable to verify the first certificate verify
>> return:1
>
> Whereas, for one of the ones for which SSLLabs *only* complains
> that the chain "contains anchor," I get (all identifying fields
> changed to protect the innocent):
>
>> depth=2 C = US, O = "Entrust, Inc.", OU = See
>> www.entrust.net/legal-terms, OU = "(c) 2009 Entrust, Inc. - for
>> authorized use only", CN = Entrust Root Certification Authority -
>> G2 verify return:1 depth=1 C = US, O = "Entrust, Inc.", OU = See
>> www.entrust.net/legal-terms, OU = "(c) 2012 Entrust, Inc. - for
>> authorized use only", CN = Entrust Certification Authority - L1K
>> verify return:1 depth=0 C = GUE, ST = Quendor, L = Flatheadia, O
>> = "Frobnitz, Inc.", CN = frobnitz.com verify return:1
>
> I can't tell any difference in the keystore structure between the
> two, and browsers don't show anything amiss. Does anybody have any
> insights into why the keystores would behave differently in SSLLabs
> and "openssl s-client -showcerts"?

So you have two cases:

1. Too many certs
2. Not enough certs

In case (1) can you confirm that the following certificates are
present in your keystore?

- - Root
- - Intermediate
- - Server

To fix the error, you should only have to remove the root certificate
from the keystore. Remember to back-up your keystore before making any
changes to it.

In case(2) can you show us what certificates are present in your keystor
e?

Something like:

$ keytool -verbose -list -keystore server.jks

For each keystore.

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zx3UACgkQHPApP6U8
pFjkkhAAo7cH9IaoZsip7N+6x588VszU2XGWfqmsfJAIYd//Zp7tIGPIGlF/dzrV
SPCV5lXuT4Ve7VWfrUtRiCNV9XbY3xyOqAYxDrnGKazK/2Zi/eZdtxr7nSOvWcuS
CSHQyjV8qHGFn9yAKVL3EikRFUylu05Frrdg3CoyQIwW32k5AjjV6JySRalaq9tq
lzZcCd0fzf42odGnTvU+5cNO6mjkjqbMZwSRKrz/K3eamZN1AfKz8n5SIxPwafoD
jZ8nmVqmNst1h1do2DLo6WlYkcM9jCPbVPFwnVa4Qi2w9Edx90G1pQK4rlK2i1QV
6BwDAyesP2+kkqyKw0im6iz3yomByCAb2q/Nq7Ybw4jIN92HlUZgCvoj2ozQsRQq
XRS3Ctzv+o24dYtdUQ3/wVc503kFIBflSSE0HgwgkFwXXCWDHZwA/5RMExxBFUKa
oZJKVa/vi7UT9BopRJFRCL98VDtXmqMjD3UoFlWGDSoajbMVAw1/f3yTFxcZt8fF
aLwfOc/t57N9h6VKrW2o555vh4HwGs8r7YK93EOceqVaa1F1MSlozx5Y3SqVG32P
4anT25DoEhffBUL6LfqQwFAm6cyyXqnt6cOyzXYqLQCLVd7+HZUThLYAOWIhEgvw
59KAMAR/o+oR9WsSFuZGp02WiYGe9GpDhl7zW/8+9bdL11xBlBk=
=yLzD
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org