On Thu, Apr 3, 2014 at 2:58 PM, <jeffery.scott.cr...@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.cr...@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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@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
