Re: Help with Tomcat Applications not listening
Larry, Make sure that you’re closing any resource that you’ve opened. Jeff Sent from Windows Mail From: Cohen, Laurence Sent: Wednesday, September 2, 2015 2:54 PM To: Tomcat Users List Hi, We have a webserver and an appserver, and the webserver talks to the appserver on port 8007. Every once the communication will stop, and we will notice an error on the webserver saying that it can't talk to the appserver. When this happens, I will run a netstat -an |grep 8007 on the appserver, and there are hundreds of connections to that port. When I restart the app, it will be back to about 10 connections, and they will start growing again. I'm trying to figure out why they are growing so quickly, and why they aren't dying when the connection is no longer needed. Any help would be appreciated. Thanks, Larry Cohen
RE: Tomcat 7.0.55 Not loading truststore or keystore
>> openssl s_client -tls1 -connect server-dns-name:15305 -CAfile >> server-cert-with-intermediate-and-root-in-one-file.cer -cert >> client-public-key.cer -key client-private-key.key -pass >> pass:client-private-key-password I've had trouble when there are more certificate packaged in the same file as the root certificate. If you can separate the certificates your problem should go away. Jeff Crump Sent from Mail for Windows 10 From: George Stanchev Sent: Tuesday, September 1, 2015 1:02 PM To: Tomcat Users List Subject: RE: Tomcat 7.0.55 Not loading truststore or keystore Hi Diarmuid, We have run similar issue with client cert SSL. Is your 3rd party web service hosted on Windows/IIS? George -Original Message- From: dmccrthy [mailto:dmccr...@gmail.com] Sent: Tuesday, September 01, 2015 11:07 AM To: Tomcat Users List Subject: Tomcat 7.0.55 Not loading truststore or keystore Hi All, I am having trouble getting Tomcat to load a truststore and keystore. This seems to be a basic configuration issue but I can't figure out what the problem is. Any insights would be gratefully received. The scenario is: * A 3rd party web application is deployed in Tomcat * The 3rrd party web application is making outbound HTTPS connections to a 3rd party web service * Tomcat JVM parameters are configured with -Djavax.net.ssl.trustStore=d:\Tomcat_ENV1\conf\tomcat_truststore.jks -Djavax.net.ssl.trustStorePassword= -Djavax.net.ssl.keyStore=d:\Tomcat_ENV1\conf\DWCHASSMESA002_keystore.jks -Djavax.net.ssl.keyStorePassword= -Dhttps.protocols="TLSv1" -Djavax.net.debug=ALL * Both truststore and keystore are JKS * Mutual authentication is used for the SSL handshake * There are no errors in the Tomcat logs to indicate a problem with the truststore and keystore * The Tomcat logs show the server-side certificate being downloaded but not reporting the expected lines Found trusted certificate: matching alias: Or for the keystore, I am expecting to see a log that it is loading the keystore (example below), but there is no sign that the keystore is being loaded. I got the log extract below from a standalone java client which successfully connects using MA to the remote service. keyStore is : c:\temp\DWCHASSMESA002.pfx keyStore type is : PKCS12 keyStore provider is : init keystore init keymanager of type SunX509 *** found key for : dwchassmesa002 chain [0] = [ * The Tomcat logs show that the SSL handshake gets as far as the ClientKeyExchange, but there is no client certificate sent and the handshake terminates with "Software caused connection abort: recv failed". On DataPower the error is that the client is not sending the certificate. http-bio-8080-exec-2, READ: TLSv1 Handshake, length = 13 *** CertificateRequest Cert Types: RSA, DSS Cert Authorities: [read] MD5 and SHA1 hashes: len = 9 : 0D 00 00 05 02 01 02 00 00 . *** ServerHelloDone [read] MD5 and SHA1 hashes: len = 4 : 0E 00 00 00 *** Certificate chain *** *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 [write] MD5 and SHA1 hashes: len = 269 http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 269 [Raw write]: length = 274 : 16 03 01 01 0D 0B 00 00 03 00 00 00 10 00 01 02 0110: 2E 32 .2 SESSION KEYGEN: PreMaster Secret: http-bio-8080-exec-2, WRITE: TLSv1 Handshake, length = 48 http-bio-8080-exec-2, waiting for close_notify or alert: state 1 http-bio-8080-exec-2, Exception while waiting for close java.net.SocketException: Software caused connection abort: recv failed http-bio-8080-exec-2, handling exception: java.net.SocketException: Software caused connection abort: recv failed %% Invalidated: [Session-163, TLS_RSA_WITH_AES_128_CBC_SHA] http-bio-8080-exec-2, called close() http-bio-8080-exec-2, called closeInternal(true) http-bio-8080-exec-2, called closeSocket( We are using the software below on the client environment: * Java(TM) SE Runtime Environment (build 1.7.0_67-b01) * Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode) * JCE Unlimited Security: No * Apache Tomcat/7.0.55 * Microsoft Windows Server 2008 R2 Enterprise 64-bit Analysis Steps == 1) Openssl connects with MA parameters connects with no errors openssl s_client -tls1 -connect server-dns-name:15305 -CAfile server-cert-with-intermediate-and-root-in-one-file.cer -cert client-public-key.cer -key client-private-key.key -pass pass:client-private-key-password New, TLSv1/SSLv3, Cipher is AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1 Cipher: AES256-SHA Session-ID: 893D24420CC89DED5E8E0E18C3D97270C3DD04B7A4B86602D5B34FC5E58DDE8F Session-ID-ctx: Master-Key:
Re: Replaced a self-signed key with a GoDaddy key
Mark, It turns out that the root certificate was a combination of g1 and g2, and that this causes a problem for keytool. I downloaded the single root certificate gdroot-g2.crt and used it to replace the root certificate. That fixed the problems. Jeff Sent from Windows Mail From: Mark Thomas Sent: Friday, August 7, 2015 1:40 PM To: Tomcat Users List On 7 August 2015 19:01:34 BST, jeffery.scott.cr...@gmail.com wrote: I’ve been using Tomcat for about fours years. I’ve developed websites and services that used certificates based upon SHA1. Today I purchased a new certificate from GoDaddy based upon using “-sigalg SHA256withRSA”. So for this new service I executed the following commands in the directory of the keystore: keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore tomcat.keystore keytool -certreq -keyalg RSA -alias tomcat -file csr.txt -keystore tomcat.keystore sent the csr.txt to GoDadday and received the certificate files. keytool -delete -alias tomcat -keystore tomcat.keystore You deleted the key at this point. There should be no need to do this. Mark keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file xx.crt If I copy over the new tomcat.keystore with a backup of the original everything works. My Tomcat 8.0.23 on CentOS 6.5 is configure with three virtual hosts in server.xml; the following is for the one with the GoDaddy certificate. I’m doing them one-at-time. Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.startup.VersionLoggerListener / Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / Service name=System Connector port=8080 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true keyAlias=tomcat keystoreFile=/opt/tomcat/system/tomcat.keystore keystorePass=xxx clientAuth=false sslProtocol=TLS / Engine name=System defaultHost=.com Host name=.com appBase=webapps/.com unpackWARs=true autoDeploy=true Aliaswww..com/Alias Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=.com suffix=.log pattern=common / /Host /Engine /Service …. /Server Each service is on a different IP address and I’ve been redirecting 80 to 8080 and 443 to 8443. This has been working fine until I replaced the key. This is from the catalina.out file: 07-Aug-2015 12:43:02.493 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler [http-nio-xxx.xxx.xxx.xxx-8443] java.io.IOException: Alias name tomcat does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:599) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:537) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:358) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:737) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:457) at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:120) at org.apache.catalina.connector.Connector.initInternal(Connector.java:960) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:567) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:851) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:576) at org.apache.catalina.startup.Catalina.load(Catalina.java:599) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484) 07-Aug-2015 12:43:02.496 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]]
Replaced a self-signed key with a GoDaddy key
I’ve been using Tomcat for about fours years. I’ve developed websites and services that used certificates based upon SHA1. Today I purchased a new certificate from GoDaddy based upon using “-sigalg SHA256withRSA”. So for this new service I executed the following commands in the directory of the keystore: keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore tomcat.keystore keytool -certreq -keyalg RSA -alias tomcat -file csr.txt -keystore tomcat.keystore sent the csr.txt to GoDadday and received the certificate files. keytool -delete -alias tomcat -keystore tomcat.keystore keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file xx.crt If I copy over the new tomcat.keystore with a backup of the original everything works. My Tomcat 8.0.23 on CentOS 6.5 is configure with three virtual hosts in server.xml; the following is for the one with the GoDaddy certificate. I’m doing them one-at-time. Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.startup.VersionLoggerListener / Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / Service name=System Connector port=8080 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true keyAlias=tomcat keystoreFile=/opt/tomcat/system/tomcat.keystore keystorePass=xxx clientAuth=false sslProtocol=TLS / Engine name=System defaultHost=.com Host name=.com appBase=webapps/.com unpackWARs=true autoDeploy=true Aliaswww..com/Alias Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=.com suffix=.log pattern=common / /Host /Engine /Service …. /Server Each service is on a different IP address and I’ve been redirecting 80 to 8080 and 443 to 8443. This has been working fine until I replaced the key. This is from the catalina.out file: 07-Aug-2015 12:43:02.493 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler [http-nio-xxx.xxx.xxx.xxx-8443] java.io.IOException: Alias name tomcat does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:599) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:537) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:358) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:737) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:457) at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:120) at org.apache.catalina.connector.Connector.initInternal(Connector.java:960) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:567) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:851) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:576) at org.apache.catalina.startup.Catalina.load(Catalina.java:599) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484) 07-Aug-2015 12:43:02.496 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[HTTP/1.1-8443]] org.apache.catalina.LifecycleException: Failed to initialize component [Connector[HTTP/1.1-8443]] at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:106) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:567) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102)
Re: Replaced a self-signed key with a GoDaddy key
keytool -delete -alias tomcat -keystore tomcat.keystore You deleted the key at this point. There should be no need to do this. Mark Mark, I rekeyed my certificate from a newly created tomcat.keystore and imported in the root and immediate certificates, then I got this when I imported my certificate: keytool error: java.lang.Exception: Failed to establish chain from reply Jeff Sent from Windows Mail From: Mark Thomas Sent: Friday, August 7, 2015 1:40 PM To: Tomcat Users List On 7 August 2015 19:01:34 BST, jeffery.scott.cr...@gmail.com wrote: I’ve been using Tomcat for about fours years. I’ve developed websites and services that used certificates based upon SHA1. Today I purchased a new certificate from GoDaddy based upon using “-sigalg SHA256withRSA”. So for this new service I executed the following commands in the directory of the keystore: keytool -keysize 2048 -genkey -alias tomcat -keyalg RSA -sigalg SHA256withRSA -keystore tomcat.keystore keytool -certreq -keyalg RSA -alias tomcat -file csr.txt -keystore tomcat.keystore sent the csr.txt to GoDadday and received the certificate files. keytool -delete -alias tomcat -keystore tomcat.keystore You deleted the key at this point. There should be no need to do this. Mark keytool -import -alias root -keystore tomcat.keystore -trustcacerts -file gd_bundle-g2-g1.crt keytool -import -alias intermed -keystore tomcat.keystore -trustcacerts -file gdig2.crt keytool -import -alias tomcat -keystore tomcat.keystore -trustcacerts -file xx.crt If I copy over the new tomcat.keystore with a backup of the original everything works. My Tomcat 8.0.23 on CentOS 6.5 is configure with three virtual hosts in server.xml; the following is for the one with the GoDaddy certificate. I’m doing them one-at-time. Server port=8005 shutdown=SHUTDOWN Listener className=org.apache.catalina.startup.VersionLoggerListener / Listener className=org.apache.catalina.core.AprLifecycleListener SSLEngine=on / Listener className=org.apache.catalina.core.JreMemoryLeakPreventionListener / Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener / Listener className=org.apache.catalina.core.ThreadLocalLeakPreventionListener / Service name=System Connector port=8080 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 connectionTimeout=2 redirectPort=8443 / Connector port=8443 address=xxx.xxx.xxx.xxx protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true keyAlias=tomcat keystoreFile=/opt/tomcat/system/tomcat.keystore keystorePass=xxx clientAuth=false sslProtocol=TLS / Engine name=System defaultHost=.com Host name=.com appBase=webapps/.com unpackWARs=true autoDeploy=true Aliaswww..com/Alias Valve className=org.apache.catalina.valves.AccessLogValve directory=logs prefix=.com suffix=.log pattern=common / /Host /Engine /Service …. /Server Each service is on a different IP address and I’ve been redirecting 80 to 8080 and 443 to 8443. This has been working fine until I replaced the key. This is from the catalina.out file: 07-Aug-2015 12:43:02.493 SEVERE [main] org.apache.coyote.AbstractProtocol.init Failed to initialize end point associated with ProtocolHandler [http-nio-xxx.xxx.xxx.xxx-8443] java.io.IOException: Alias name tomcat does not identify a key entry at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:599) at org.apache.tomcat.util.net.jsse.JSSESocketFactory.getKeyManagers(JSSESocketFactory.java:537) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:358) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:737) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:457) at org.apache.coyote.http11.AbstractHttp11JsseProtocol.init(AbstractHttp11JsseProtocol.java:120) at org.apache.catalina.connector.Connector.initInternal(Connector.java:960) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:567) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:851) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:576) at org.apache.catalina.startup.Catalina.load(Catalina.java:599) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:310) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:484) 07-Aug-2015
Re: Valid certificate chain failing with unable to find valid certification path to requested
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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.x.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.xx.net) is correctly listed in the certificate.
Common name: www.x.net
SANs: www.xx.net, xx.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
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.x.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.xx.net) is correctly listed in the
certificate. Common name: www.x.net SANs:
www.xx.net, xx.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
Re: Valid certificate chain failing with unable to find valid certification path to requested
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
