You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by je...@gmail.com on 2014/04/03 20:25:33 UTC
Valid certificate chain failing with "unable to find valid certification path to requested "
I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server; 8 processor cores, 18 GB RAM.
My java client is opening an HttpsURLConnection:
SSLContext sc = SSLContext.getInstance("TLS");
sc.init(null, null, null);
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
URL url = new URL(urlText);
HttpsURLConnection urlConnection = (HttpsURLConnection) url.openConnection();
urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
urlConnection.setDoOutput(true);
try (OutputStreamWriter output = new OutputStreamWriter(urlConnection.getOutputStream(), "UTF-8")) {
output.write(msg.writeNodes(false));
output.write("\n");
output.flush();
}
On getting the urlConnection.getOutputStream() the following exception is thrown:
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException:
unable to find valid certification path to requested target
If I set the SSLContext to accept all hosts it works.
I can see the servlet’s “Hello World” message from a web browser. Chrome says that it has a valid certificate.
I verified that the certificates were valid using SSLShopper:
www.xxxxxxxxx.net resolves to xxx.xxx.xxx.xxx
Server Type: Apache/2.2.15 (CentOS)
The certificate should be trusted by all major web browsers (all the correct intermediate certificates are installed).
The certificate was issued by GoDaddy.
The certificate will expire in 364 days.
The hostname (www.xxxxxxxxxx.net) is correctly listed in the certificate. Common name: www.xxxxxxxxx.net
SANs: www.xxxxxxxxxx.net, xxxxxxxxxx.net
Valid from April 3, 2014 to April 3, 2015
Serial Number: 0431cbc326fefc
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Secure Certificate Authority - G2
Common name: Go Daddy Secure Certificate Authority - G2
Organization: GoDaddy.com, Inc.
Location: Scottsdale, Arizona, US
Valid from May 3, 2011 to May 3, 2031
Serial Number: 7 (0x7)
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Root Certificate Authority - G2
Common name: Go Daddy Root Certificate Authority - G2
Organization: GoDaddy.com, Inc.
Location: Scottsdale, Arizona, US
Valid from August 31, 2009 to December 31, 2037
Serial Number: 0 (0x0)
Signature Algorithm: sha256WithRSAEncryption
Issuer: Go Daddy Root Certificate Authority - G2
I have similar setup. The keystores are in the same folder, the server.xml are the same except for the hostnames and the keystore password. The server with the problem is not using the default keystorepassword of "changeit"
Any help would be greatly appreciated.
Jeff Crump
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by Ognjen Blagojevic <og...@gmail.com>.
Chris,
On 4.4.2014 16:27, Christopher Schultz wrote:
> So they don't have a big "Daddy" certificate that has signed all of
> their intermediate certificates? Boo. That would fix nearly everything.
Actually, having different root certificates, one for SHA-1, and one for
SHA-2 is recommended migration practice in order to dicth all SHA-1
certificates at some point in time, for security reasons.
>> FTR, GoDaddy or any other CA can't just "add" certificate to Java
>> root certificates, but it must apply at Oracle for inclusion.
>
> If the problem is that the client trusts GoDaddy's ROOT certificate
> and the server's certificate was signed by GoDaddy's intermediate
> certificate (which should have been in turn signed by the ROOT
> certificate), then the solution is to include the intermediate
> certificate (or certificates... some CAs have longer chains) in your
> keystore and configure Tomcat to serve both the server's cert and the
> intermediate cert.
Configuration for JSSE connectors is somewhat different than APR. For
JSSE, you don't configure Tomcat to serve intermediate certificates, but
you import them to your keystore before you import server certificate.
By doing so, JSSE will serve the complete certificate chain to the client.
>
>>>> This is what I think is the relevant part: [3]: ObjectId:
>>>> 2.5.29.19 Criticality=true BasicConstraints:[ CA:false
>>>> PathLen:2147483647 ]
>>
>> It just says that server certificate you have cannot be used to
>> sign other certificates, nothing else. That is irrelevant for you.
>
> Depending upon where this came from (there was no context given), you
> are correct. If this is information from the GoDaddy certificate, then
> it's likely an intermediate certificate and not a root cert.
x.509v3 Basic Constraints CA:true means that the certificate may sign
other certificates. It would be impossible that GoDaddy signing
certificate (either root or intermediate) have CA set to false.
Therefore I assumed the information is about server certificate.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Ognjen,
On 4/4/14, 4:14 AM, Ognjen Blagojevic wrote:
> On 4.4.2014 5:23, Toby Lazar wrote:
>>> I've run my client program with the -Djavax.net.debug=all
>>> 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.
>
> +1.
>
> It seems to be known issue with GoDaddy G2 certificate:
>
> http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
>
>
>
> "[GoDaddy] have 2 CA servers, one called Class 2 CA and the other
> called G2 CA. Their Class 2 CA signs all SHA-1 certificates, while
> the G2 CA signs all their SHA-2 certificates. This is where the
> problem lies - GoDaddy has not added their newer G2 CA server to
> the default java truststore - causing default java installations to
> not trust it's authority, and hence, does not trust your chained
> certificate. The work-around until GoDaddy adds the G2 CA server to
> the default truststore is to simply rekey your cert using SHA-1
> as-to get a cert signed by the Class 2 CA server. Rekeying is free
> for GoDaddy customers until your cert expires (obviously)."
So they don't have a big "Daddy" certificate that has signed all of
their intermediate certificates? Boo. That would fix nearly everything.
> FTR, GoDaddy or any other CA can't just "add" certificate to Java
> root certificates, but it must apply at Oracle for inclusion.
If the problem is that the client trusts GoDaddy's ROOT certificate
and the server's certificate was signed by GoDaddy's intermediate
certificate (which should have been in turn signed by the ROOT
certificate), then the solution is to include the intermediate
certificate (or certificates... some CAs have longer chains) in your
keystore and configure Tomcat to serve both the server's cert and the
intermediate cert.
>>> This is what I think is the relevant part: [3]: ObjectId:
>>> 2.5.29.19 Criticality=true BasicConstraints:[ CA:false
>>> PathLen:2147483647 ]
>
> It just says that server certificate you have cannot be used to
> sign other certificates, nothing else. That is irrelevant for you.
Depending upon where this came from (there was no context given), you
are correct. If this is information from the GoDaddy certificate, then
it's likely an intermediate certificate and not a root cert.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPsFMAAoJEBzwKT+lPKRYrCkQALBDQmaPZfjy1bAwBGC36Yg9
fIqCeI37izMwCgaiGGSNw9mA6GUyJoEixzXorlD6kje/oroJveq/AEaBMZO6eWJ7
OSVqUbcFNFNF+waVSskIDU0+4eLZHYvAU5t8jAJpVy6Jenw0QHrYV3rt2OpE1w8w
w+sFg7FvqYth4oHVsSmrnBP1ncA90Bpsv49AXlQUhKQ5ielGKfJVcciBNhNRbZiF
atNQxcR+Xm++2mDJIx4l0sfS+XzEVY655QBpys02H051lfg1VeOMLroFtTdckhQZ
ECsIGPs2Ue69T4wjByY+pPeQ9HW77kKurVgV6pUbZaGTdLNV0gQqHNBVj5hNdriN
wNMZFFSWywnzX/UP+N1bbAfXm2Y4i8n7UQyQWIa+tY/74PzvUrIgZfYsxMeVM5Rz
erZvyIQaVBN4zdPgL9nHQNb4bMza42apNrwWeOrZDLPwv23EOD0E4tO/nkg95+7W
fobXN4+hQoK7s7PqKdkdIafwsnu7Kv1MFR+UatZ6evayOrE8k9MbQDQXYRZ1/5/N
DOavfNOOe73+AeJDXcaDNprGjWvzCEUCXfCPv7b76j9pd+o4zm+LGYQLNYcrE8lJ
uqXfgvijaRlDueNId7Qz+9wgkaZnUVtc/plyK47/4NjQ0RNgYWKvo2CAtvbBHR/u
qrEmBVjQuLKEek1TDRiw
=5CiA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid certification path to requested "
Posted by je...@gmail.com.
Ognjen,
You were correct. The GoDaddy GA2 certificate was not in the root distributions. I re-keyed it to GA1 and that fixed the problems.
Thank you all.
Jeff Crump
Sent from Windows Mail
From: Ognjen Blagojevic
Sent: Friday, April 4, 2014 3:14 AM
To: Tomcat Users List
On 4.4.2014 5:23, Toby Lazar wrote:
>> I've run my client program with the -Djavax.net.debug=all 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.
+1.
It seems to be known issue with GoDaddy G2 certificate:
http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
"[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA
signs all their SHA-2 certificates. This is where the problem lies -
GoDaddy has not added their newer G2 CA server to the default java
truststore - causing default java installations to not trust it's
authority, and hence, does not trust your chained certificate. The
work-around until GoDaddy adds the G2 CA server to the default
truststore is to simply rekey your cert using SHA-1 as-to get a cert
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers
until your cert expires (obviously)."
FTR, GoDaddy or any other CA can't just "add" certificate to Java root
certificates, but it must apply at Oracle for inclusion.
>> This is what I think is the relevant part:
>> [3]: ObjectId: 2.5.29.19 Criticality=true
>> BasicConstraints:[
>> CA:false
>> PathLen:2147483647
>> ]
It just says that server certificate you have cannot be used to sign
other certificates, nothing else. That is irrelevant for you.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by Ognjen Blagojevic <og...@gmail.com>.
On 4.4.2014 5:23, Toby Lazar wrote:
>> I've run my client program with the -Djavax.net.debug=all 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.
+1.
It seems to be known issue with GoDaddy G2 certificate:
http://stackoverflow.com/questions/18746565/godaddy-ssl-cert-not-working-with-java
"[GoDaddy] have 2 CA servers, one called Class 2 CA and the other called
G2 CA. Their Class 2 CA signs all SHA-1 certificates, while the G2 CA
signs all their SHA-2 certificates. This is where the problem lies -
GoDaddy has not added their newer G2 CA server to the default java
truststore - causing default java installations to not trust it's
authority, and hence, does not trust your chained certificate. The
work-around until GoDaddy adds the G2 CA server to the default
truststore is to simply rekey your cert using SHA-1 as-to get a cert
signed by the Class 2 CA server. Rekeying is free for GoDaddy customers
until your cert expires (obviously)."
FTR, GoDaddy or any other CA can't just "add" certificate to Java root
certificates, but it must apply at Oracle for inclusion.
>> This is what I think is the relevant part:
>> [3]: ObjectId: 2.5.29.19 Criticality=true
>> BasicConstraints:[
>> CA:false
>> PathLen:2147483647
>> ]
It just says that server certificate you have cannot be used to sign
other certificates, nothing else. That is irrelevant for you.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid
certification path to requested "
Posted by Toby Lazar <tl...@capitaltg.com>.
On Thu, Apr 3, 2014 at 10:03 PM, <je...@gmail.com> 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
client.
>
> I've run my client program with the -Djavax.net.debug=all 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: 2.5.29.19 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.
Toby
> 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.)
>
> --
> JHHL
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
Re: Valid certificate chain failing with "unable to find valid certification path to requested "
Posted by je...@gmail.com.
I tried ssllabs but it doesn't support SSL on port 8443, but digicert did show that everything was correct in the chain.
I've run my client program with the -Djavax.net.debug=all option. First it listed out all of the trusted authorities. Mine is GoDaddy and this is the record:
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: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen:2147483647
]
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.)
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by "James H. H. Lampert" <ja...@touchtonecorp.com>.
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.)
--
JHHL
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by Ognjen Blagojevic <og...@gmail.com>.
On 4.4.2014 0:27, Toby Lazar wrote:
> As others have noted here on other threads, you can use:
>
> http://portecle.sourceforge.net/
>
> to see exactly which certificates your server is providing clients (Examine
> SSL/TLS connection). Viewing server certificates via browsers can be
> misleading since they don't distinguish within the chain between
> certificates provided by the server and those already trusted by the client
> (browser).
You also may double check your chain using other online tools like:
https://www.ssllabs.com/ssltest/
http://www.digicert.com/help/
I never used SSLShopper, so I don't know how reliable it is.
Another way to check certificate chain directly in server keystore is
keytool -list -keystore server.jks -v
To check Chris' assumption about missing ROOT certificate on the client,
you may turn on TLS debugging on the client using JVM option
-Djavax.net.debug=all
At start it will print all root certificates trusted by the client. It
may reveal that your system ROOT CA list on the client is outdated,
messed up, or overriden with e.g. JVM option -Djavax.net.ssl.trustStore.
It will also print TLS handshake details.
Jefferey:
> The hostname (www.xxxxxxxxxx.net) is correctly listed in the
certificate. Common name: www.xxxxxxxxx.net
> SANs: www.xxxxxxxxxx.net, xxxxxxxxxx.net
Check if your Java code indeed uses one of those URL's listed in the
certificate (www.xxxxxxxxxx.net, xxxxxxxxxx.net), and not some third one
not listed in the certificate, or IP address.
-Ognjen
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Valid certificate chain failing with "unable to find valid
certification path to requested "
Posted by Toby Lazar <tl...@capitaltg.com>.
On Thu, Apr 3, 2014 at 2:58 PM, <je...@gmail.com> wrote:
> Chris,
>
>
>
>
>
>
> Sent from Windows Mail
>
>
>
>
>
> From: Christopher Schultz
> Sent: Thursday, April 3, 2014 1:55 PM
> To: Tomcat Users List
>
>
>
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Jeffrey,
>
> On 4/3/14, 2:25 PM, jeffery.scott.crump@gmail.com wrote:
> > I'm using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
> > 8 processor cores, 18 GB RAM.
> >
> >
> > My java client is opening an HttpsURLConnection:
> >
> >
> > SSLContext sc = SSLContext.getInstance("TLS"); sc.init(null, null,
> > null);
> > HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
> >
> >
> URL url = new URL(urlText);
> > HttpsURLConnection urlConnection = (HttpsURLConnection)
> > url.openConnection();
> > urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
> > urlConnection.setDoOutput(true); try (OutputStreamWriter output =
> > new OutputStreamWriter(urlConnection.getOutputStream(), "UTF-8"))
> > { output.write(msg.writeNodes(false)); output.write("\n");
> > output.flush(); }
>
> Looks fairly innocuous.
>
> > On getting the urlConnection.getOutputStream() the following
> > exception is thrown:
> >
> >
> > javax.net.ssl.SSLHandshakeException:
> > sun.security.validator.ValidatorException: PKIX path building
> > failed: sun.security.provider.certpath.SunCertPathBuilderException:
> > unable to find valid certification path to requested target
> >
> > If I set the SSLContext to accept all hosts it works.
> >
> >
> > I can see the servlet's "Hello World" message from a web browser.
> > Chrome says that it has a valid certificate.
> >
> >
> > I verified that the certificates were valid using SSLShopper:
> >
> > www.xxxxxxxxx.net resolves to xxx.xxx.xxx.xxx
> >
> > Server Type: Apache/2.2.15 (CentOS) The certificate should be
> > trusted by all major web browsers (all the correct intermediate
> > certificates are installed). The certificate was issued by GoDaddy.
> > The certificate will expire in 364 days.
> >
> > The hostname (www.xxxxxxxxxx.net) is correctly listed in the
> > certificate. Common name: www.xxxxxxxxx.net SANs:
> > www.xxxxxxxxxx.net, xxxxxxxxxx.net Valid from April 3, 2014 to
> > April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
> > sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
> > Authority - G2
> >
> > Common name: Go Daddy Secure Certificate Authority - G2
> > Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
> > Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
> > Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> > Certificate Authority - G2
> >
> > Common name: Go Daddy Root Certificate Authority - G2 Organization:
> > GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
> > August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
> > Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> > Certificate Authority - G2
> >
> >
> > I have similar setup. The keystores are in the same folder, the
> > server.xml are the same except for the hostnames and the keystore
> > password. The server with the problem is not using the default
> > keystorepassword of "changeit"
>
> JSSE is probably missing an intermediate or root CA certificate that
> you need.
>
> Are you saying that you have one server that works okay and another
> that does not? If so, the problem is likely that your non-working
> server requires an additional intermediate certificate that most
> browsers have, but that JSSE does not. (JSSE does not really keep up
> well, honestly.)
>
> Are either of the GoDaddy certs above served directly by your web
> server? Your chain length is 3 (from CA root to your cert), but the
> question is whether you are serving only 1 (your own) or 2 (your own +
> GoDaddy's intermediate) certificates.
>
> If you can ship a trust store with the client, then you can add
> whatever (root or otherwise) certificates you need to trust. The code
> is a little messy, but I was able to adapt code I borrowed from Tomcat
> to allow me to connect to an HTTPS endpoint using an on-disk trust
> store and HttpURLConnection.
>
> Let me know if that code would be useful to you.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
> 8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
> N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
> PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
> BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
> H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
> 4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
> b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
> k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
> 6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
> Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
> 9BsFBBA21UryM6HZNVXt
> =dXBw
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
>
>
> They are actually two different services based upon the same type of
> design. The first service has been up and running for about a year. I was
> moving the development server to a production environment.
>
>
> First I'll try and update the blade's root certificates. Shipping out
> client certificates is not really an option.
>
>
> Thank you for your insight. I'll let you know if it's a missing root
> certificate.
>
>
> Jeff
As others have noted here on other threads, you can use:
http://portecle.sourceforge.net/
to see exactly which certificates your server is providing clients (Examine
SSL/TLS connection). Viewing server certificates via browsers can be
misleading since they don't distinguish within the chain between
certificates provided by the server and those already trusted by the client
(browser).
Toby
Re: Valid certificate chain failing with "unable to find valid certification path to requested "
Posted by je...@gmail.com.
Chris,
Sent from Windows Mail
From: Christopher Schultz
Sent: Thursday, April 3, 2014 1:55 PM
To: Tomcat Users List
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.crump@gmail.com wrote:
> I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
> 8 processor cores, 18 GB RAM.
>
>
> My java client is opening an HttpsURLConnection:
>
>
> SSLContext sc = SSLContext.getInstance("TLS"); sc.init(null, null,
> null);
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
>
URL url = new URL(urlText);
> HttpsURLConnection urlConnection = (HttpsURLConnection)
> url.openConnection();
> urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
> urlConnection.setDoOutput(true); try (OutputStreamWriter output =
> new OutputStreamWriter(urlConnection.getOutputStream(), "UTF-8"))
> { output.write(msg.writeNodes(false)); output.write("\n");
> output.flush(); }
Looks fairly innocuous.
> On getting the urlConnection.getOutputStream() the following
> exception is thrown:
>
>
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building
> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target
>
> If I set the SSLContext to accept all hosts it works.
>
>
> I can see the servlet’s “Hello World” message from a web browser.
> Chrome says that it has a valid certificate.
>
>
> I verified that the certificates were valid using SSLShopper:
>
> www.xxxxxxxxx.net resolves to xxx.xxx.xxx.xxx
>
> Server Type: Apache/2.2.15 (CentOS) The certificate should be
> trusted by all major web browsers (all the correct intermediate
> certificates are installed). The certificate was issued by GoDaddy.
> The certificate will expire in 364 days.
>
> The hostname (www.xxxxxxxxxx.net) is correctly listed in the
> certificate. Common name: www.xxxxxxxxx.net SANs:
> www.xxxxxxxxxx.net, xxxxxxxxxx.net Valid from April 3, 2014 to
> April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
> sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
> Authority - G2
>
> Common name: Go Daddy Secure Certificate Authority - G2
> Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
> Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
> Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> Certificate Authority - G2
>
> Common name: Go Daddy Root Certificate Authority - G2 Organization:
> GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
> August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
> Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> Certificate Authority - G2
>
>
> I have similar setup. The keystores are in the same folder, the
> server.xml are the same except for the hostnames and the keystore
> password. The server with the problem is not using the default
> keystorepassword of "changeit"
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
They are actually two different services based upon the same type of design. The first service has been up and running for about a year. I was moving the development server to a production environment.
First I’ll try and update the blade’s root certificates. Shipping out client certificates is not really an option.
Thank you for your insight. I’ll let you know if it’s a missing root certificate.
Jeff
Re: Valid certificate chain failing with "unable to find valid certification
path to requested "
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Jeffrey,
On 4/3/14, 2:25 PM, jeffery.scott.crump@gmail.com wrote:
> I’m using tomcat 7.0.50 on CentOS 6.5 on a headless blade server;
> 8 processor cores, 18 GB RAM.
>
>
> My java client is opening an HttpsURLConnection:
>
>
> SSLContext sc = SSLContext.getInstance("TLS"); sc.init(null, null,
> null);
> HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>
>
URL url = new URL(urlText);
> HttpsURLConnection urlConnection = (HttpsURLConnection)
> url.openConnection();
> urlConnection.setHostnameVerifier(DO_NOT_VERIFY);
> urlConnection.setDoOutput(true); try (OutputStreamWriter output =
> new OutputStreamWriter(urlConnection.getOutputStream(), "UTF-8"))
> { output.write(msg.writeNodes(false)); output.write("\n");
> output.flush(); }
Looks fairly innocuous.
> On getting the urlConnection.getOutputStream() the following
> exception is thrown:
>
>
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building
> failed: sun.security.provider.certpath.SunCertPathBuilderException:
> unable to find valid certification path to requested target
>
> If I set the SSLContext to accept all hosts it works.
>
>
> I can see the servlet’s “Hello World” message from a web browser.
> Chrome says that it has a valid certificate.
>
>
> I verified that the certificates were valid using SSLShopper:
>
> www.xxxxxxxxx.net resolves to xxx.xxx.xxx.xxx
>
> Server Type: Apache/2.2.15 (CentOS) The certificate should be
> trusted by all major web browsers (all the correct intermediate
> certificates are installed). The certificate was issued by GoDaddy.
> The certificate will expire in 364 days.
>
> The hostname (www.xxxxxxxxxx.net) is correctly listed in the
> certificate. Common name: www.xxxxxxxxx.net SANs:
> www.xxxxxxxxxx.net, xxxxxxxxxx.net Valid from April 3, 2014 to
> April 3, 2015 Serial Number: 0431cbc326fefc Signature Algorithm:
> sha256WithRSAEncryption Issuer: Go Daddy Secure Certificate
> Authority - G2
>
> Common name: Go Daddy Secure Certificate Authority - G2
> Organization: GoDaddy.com, Inc. Location: Scottsdale, Arizona, US
> Valid from May 3, 2011 to May 3, 2031 Serial Number: 7 (0x7)
> Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> Certificate Authority - G2
>
> Common name: Go Daddy Root Certificate Authority - G2 Organization:
> GoDaddy.com, Inc. Location: Scottsdale, Arizona, US Valid from
> August 31, 2009 to December 31, 2037 Serial Number: 0 (0x0)
> Signature Algorithm: sha256WithRSAEncryption Issuer: Go Daddy Root
> Certificate Authority - G2
>
>
> I have similar setup. The keystores are in the same folder, the
> server.xml are the same except for the hostnames and the keystore
> password. The server with the problem is not using the default
> keystorepassword of "changeit"
JSSE is probably missing an intermediate or root CA certificate that
you need.
Are you saying that you have one server that works okay and another
that does not? If so, the problem is likely that your non-working
server requires an additional intermediate certificate that most
browsers have, but that JSSE does not. (JSSE does not really keep up
well, honestly.)
Are either of the GoDaddy certs above served directly by your web
server? Your chain length is 3 (from CA root to your cert), but the
question is whether you are serving only 1 (your own) or 2 (your own +
GoDaddy's intermediate) certificates.
If you can ship a trust store with the client, then you can add
whatever (root or otherwise) certificates you need to trust. The code
is a little messy, but I was able to adapt code I borrowed from Tomcat
to allow me to connect to an HTTPS endpoint using an on-disk trust
store and HttpURLConnection.
Let me know if that code would be useful to you.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTPa6YAAoJEBzwKT+lPKRYWO0QAI01lRXekr8ARVi/+HBcrxfZ
8gaBiWQR8Ce2Vv+U2AGP5m6bQQNCsOGkr04PdnYJSphTKJcOfbWCNyrMXMkNFwNs
N44t4Fgye3el1CoBxZo5SVFKqnfZLjDLV0vYtuMlG4frObMw/s3OXC4Hb1X7E60F
PGe0WOZtBe4pf4xSGfgERgdZuSaJH8eWoCUMHnY78sCFH/M8iAxcG6SzniKPxke2
BwAqNuENaVLvNw/uiAbgtIwdqfYCUFiV2UKyG/E++v7nQEJM7iK/+AKzNejdefo/
H0zmIdDNWKtCpP1wbnjgKxKd6/z7w6p/4WQUsDP5iFroI8xymsVkdAOqiM6zB9gP
4neQFQfKuMrU7h5iWhGoVGqe4Vmo9Q7GzyczqXDsT93buEjy/XFcXiPtiayIsMbi
b4MCRvd0jwTVZxDy0BnsnzUpfSnJetgXC/r3lA579cDTq5Q7GJAOSzlP3fCCCA5N
k2Jb/lHeeuFXokYhbUq5KvgJYh8DOjSOSoHY1A+kU0/jwqNzAXpJCmBEv/1z+apo
6mWd1+AmC2PyB7nfX9rtIxGeodErUHnUfHbRJKmK6wEipcJ4bbBbXS/OfdsMPi2f
Qdqjw3Bv+8/zEa3Pq4mc8ZegUk2bqMof1z0ycxpyjChdFfxIOM3FG5QvE6fJqREn
9BsFBBA21UryM6HZNVXt
=dXBw
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org