Hash: SHA256


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

Something like:

$ keytool -verbose -list -keystore server.jks

For each keystore.

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


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

Reply via email to