tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Toby Lazar <>
Subject Re: Valid certificate chain failing with "unable to find valid certification path to requested "
Date Fri, 04 Apr 2014 03:23:35 GMT
On Thu, Apr 3, 2014 at 10:03 PM, <> wrote:

> I tried ssllabs but it doesn't support SSL on port 8443, but digicert did
> show that everything was correct in the chain.
> Your certificate is a good certificate but it doesn't mean your client
should trust it.  ssllabs may trust a different set of issuers than your

> I've run my client program with the option. First it
> listed out all of the trusted authorities. Mine is GoDaddy and this is the
> record:

That one is not the issuer of your certificate.  GoDaddy has many issuing
certificates.  The GoDaddy certificate the client trusts expires in 2034
whereas your issuer certificates expire in 2031/2037.  Also, the DNs are
different.  Better to identify the trusted certificate by serial number and
subject key identifier.

> 04/03/2014 07:42:56 PM adding as trusted cert:
> 04/03/2014 07:42:56 PM   Subject: OU=Go Daddy Class 2 Certification
> Authority, O="The Go Daddy Group, Inc.", C=US
> 04/03/2014 07:42:56 PM   Issuer:  OU=Go Daddy Class 2 Certification
> Authority, O="The Go Daddy Group, Inc.", C=US
> 04/03/2014 07:42:56 PM   Algorithm: RSA; Serial number: 0x0
> 04/03/2014 07:42:56 PM   Valid from Tue Jun 29 12:06:20 CDT 2004 until Thu
> Jun 29 12:06:20 CDT 2034
> This is what I think is the relevant part:
> [3]: ObjectId: Criticality=true
> BasicConstraints:[
>   CA:false
>   PathLen:2147483647
> ]
> I don't think this is your problem.  Your problem is that you lack a chain
of trust from your server certificate to one that the client already
trusts.  If your server is only serving up its own server certificate and
not the intermediate one, try adding that to your config.  You can test
this out with portecle or another tool.


> How can I tell what that is or how to remove it?
> Thanks,
> Jeff
> Sent from Windows Mail
> From: James H. H. Lampert
> Sent: Thursday, April 3, 2014 8:12 PM
> To: Tomcat Users List
> I've only barely glanced at this thread, so forgive me if I'm saying
> something that's already been mentioned, or that's irrelevant.
> But yesterday, I was tearing my hair out over something similar while
> setting up a keystore for a customer: it seems that the customer's CA of
> choice had assumed that the customer was using the same keystore that
> they'd used previously (I'd created a new one because of some changes in
> ownership and location information), and so they'd signed the CSR with
> the OLD intermediate certificates, without bothering to tell anybody.
> And so every time I tried to plug the response certificate in with the
> NEW intermediates, Keytool would balk.
> I dunno what possessed me to try the old intermediates, but try them I
> did (by that time, I'd also found and installed "KeyStore Explorer," a
> nifty little open-source Keytool-replacement). (Ironically, because
> installing a CSR response certificate is a bit counter-intuitive in
> KeyStore Explorer [it's ONLY on the right-click menu, and ONLY if you
> right-click on a keypair], the keystore I made using it was worthless,
> but once I'd discovered the problem, I'd also done one with Keytool as a
> backup. Didn't find out I'd screwed up the KeyStore Explorer version
> until this afternoon, and didn't figure out the right way to do it in
> KeyStore Explorer until after I'd already put the Keytool version of the
> keystore into service.)
> --
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message