Hello, I'm using the tomcat maven plugin to deploy to an SSL-enabled host. I've pointed maven at copy of the keystore used on the tomcat server itself, so all the keys should be there. Also, I enabled java.net.ssl.debug=all, and confirmed the public key, intermediate cert, and CA cert are loaded. Yet, with TLSv1.2 on the server, the handshake failed at this point:
0070: 00 17 00 01 00 03 00 13 00 15 00 06 00 07 00 09 ................ 0080: 00 0A 00 18 00 0B 00 0C 00 19 00 0D 00 0E 00 0F ................ 0090: 00 10 00 11 00 02 00 12 00 04 00 05 00 14 00 08 ................ 00A0: 00 16 00 0B 00 02 01 00 ........ [Raw read]: length = 5 0000: 15 03 01 00 02 ..... [Raw read]: length = 2 0000: 02 28 .( main, READ: TLSv1 Alert, length = 2 main, RECV TLSv1 ALERT: fatal, handshake_failure main, called closeSocket() main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure main, called close() main, called closeInternal(true) I really had no idea how to interrupt the error - it's a bit ambiguous. I took a wild guess that maybe it was because it was trying TLSv1, and enabled 1.1 and 1 on the server - and it appeared to fix the error. So as best as I can tell, even thought tomcat 7 supports TLSv1, the tomcat maven plugin does not. I think? My two main questions would be: - is there a better way to debug this issue? - is there a way to enabled TLSv1.2 support in the tomcat maven plugin? The maven plugin is version 2.2, maven is 3.0.4 The server is tomcat 7. My certs being loaded: trustStore provider is : init truststore adding as trusted cert: Subject: CN=StartCom Class 1 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x19 Valid from Wed Oct 24 13:54:17 PDT 2007 until Tue Oct 24 13:54:17 PDT 2017 adding as trusted cert: Subject: EMAILADDRESS=shareplaylearn....@domainsbyproxy.com, CN= www.shareplaylearn.com, C=US Issuer: CN=StartCom Class 1 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x51a8eec8d76a0 Valid from Sat Jan 24 20:46:45 PST 2015 until Mon Jan 25 21:43:15 PST 2016 adding as trusted cert: Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x1 Valid from Sun Sep 17 12:46:36 PDT 2006 until Wed Sep 17 12:46:36 PDT 2036 There are some notes about unsupported ciphers.. but it doesn't look like it's the ones the client is requesting anyways: trustStore provider is : init truststore adding as trusted cert: Subject: CN=StartCom Class 1 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x19 Valid from Wed Oct 24 13:54:17 PDT 2007 until Tue Oct 24 13:54:17 PDT 2017 adding as trusted cert: Subject: EMAILADDRESS=shareplaylearn....@domainsbyproxy.com, CN= www.shareplaylearn.com, C=US Issuer: CN=StartCom Class 1 Primary Intermediate Server CA, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x51a8eec8d76a0 Valid from Sat Jan 24 20:46:45 PST 2015 until Mon Jan 25 21:43:15 PST 2016 adding as trusted cert: Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Issuer: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL Algorithm: RSA; Serial number: 0x1 Valid from Sun Sep 17 12:46:36 PDT 2006 until Wed Sep 17 12:46:36 PDT 2036
