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