Chrome ERR_BAD_SSL_CLIENT_AUTH_CERT - ssl

im developing and testing an applycation with mutual authentication TLS/SSL
i have this
Server side
jax web service on jboss 6
client side
web app
want to access with browser at my wsdl (https://mydomain:8443/myService/service?wsdl
and onFireFox everything is ok
problem is on Chrome because i got ERR_BAD_SSL_CLIENT_AUTH_CERT. Dont understand why? i have done same setting as on Firefox.
here ssl log of the server
11:49:50,499 INFORMAZIONI [STDOUT] *** ServerHelloDone
11:49:50,499 INFORMAZIONI [STDOUT] http-8443-1, WRITE: TLSv1.2 Handshake, length = 1613
11:49:50,501 INFORMAZIONI [STDOUT] http-8443-1, READ: TLSv1.2 Handshake, length = 7
11:49:50,501 INFORMAZIONI [STDOUT] *** Certificate chain
11:49:50,501 INFORMAZIONI [STDOUT] <Empty>
11:49:50,501 INFORMAZIONI [STDOUT] ***
11:49:50,501 INFORMAZIONI [STDOUT] %% Invalidated: [Session-23, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
11:49:50,501 INFORMAZIONI [STDOUT] http-8443-1, SEND TLSv1.2 ALERT: fatal, description = bad_certificate
11:49:50,502 INFORMAZIONI [STDOUT] http-8443-1, WRITE: TLSv1.2 Alert, length = 2
11:49:50,502 INFORMAZIONI [STDOUT] http-8443-1, called closeSocket()
11:49:50,502 INFORMAZIONI [STDOUT] http-8443-1, handling exception: javax.net.ssl.SSLHandshakeException: null cert chain
I imported in both browser a cert p12 format but it works only on firefox
All certificates are my own certificates

Related

Console Producer Error after Implementing with TLS/SSL

I wanted to add TLS/SSL to my kafka setup. To start with, I went through the kafka SSL documenation on main website. I have done the following:
1) Imported the signed certificates to keystore
2) Imported the root CA
3) Verified that the keystore and trust store password are correct by using keytool.
4) Started zookeeper and kafka.
5) Confirmed the following from server.log file:
Registered broker 0 at path /brokers/ids/0 with addresses:
EndPoint(localhost,9092,ListenerName(PLAINTEXT),PLAINTEXT),EndPoint(localhost,9093,ListenerName(SSL),SSL) (kafka.utils.ZkUtils)
my server.properties file have both listeners and advertised.listeners set to the following:
PLAINTEXT://localhost:9092,SSL://localhost:9093
I also have automatic topic creation enabled. When I do:
kafka-console-producer.bat --broker-list localhost:9093 --topic test_ssl --producer.config ....\config\producer.properties
I am getting the following error:
[2017-08-04 16:28:15,265] WARN Error while fetching metadata with correlation id 0 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,372] WARN Error while fetching metadata with correlation id 1 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:15,474] WARN Error while fetching metadata with correlation id 2 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,302] WARN Error while fetching metadata with correlation id 3 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,406] WARN Error while fetching metadata with correlation id 4 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
[2017-08-04 16:28:20,512] WARN Error while fetching metadata with correlation id 5 : {test_ssl=LEADER_NOT_AVAILABLE} (org.apache.kafka.clients.NetworkClient)
I tried to print out the SSL comms data using openssl
openssl s_client -connect localhost:9093 -debug -tls1 // default kafka broker configs have tlsv1 included
I get the following:
Certificate chain
0 s:/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
1 s:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
i:/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIDfDCCAmQCCQDJKjhOy8KBWjANBgkqhkiG9w0BAQsFADCBlTELMAkGA1UEBhMC
R0IxEzARBgNVBAgMClNvbWUtU3RhdGUxDzANBgNVBAcMBkxvbmRvbjEMMAoGA1UE
CgwDU0FQMRcwFQYDVQQLDA5TQVAgRmllbGRnbGFzczESMBAGA1UEAwwJbG9jYWxo
b3N0MSUwIwYJKoZIhvcNAQkBFhZtb2hhbW1lZC5tYW5uYUBzYXAuY29tMB4XDTE3
MDgwNzA5MDU0MFoXDTE5MDgwNzA5MDU0MFowajELMAkGA1UEBhMCR0IxEDAOBgNV
BAgTB1Vua25vd24xDzANBgNVBAcTBkxvbmRvbjEMMAoGA1UEChMDU0FQMRcwFQYD
VQQLEw5TQVAgRmllbGRnbGFzczERMA8GA1UEAxMITS4gTWFubmEwggEiMA0GCSqG
SIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+sGslb3XocPzigNOmwi9DRE7U6Gos+k1
ADWCS1UGDXPRuS9JocCc2oZ2GJxwipDpF+xRGmeAXIo77S/4GXFjs+DG1R8kojXn
bth3QRTsI6XAMuWOX3AHd4ob0/WSWsPLkGRggCyqU7qwvhuD+MzXB2Q0isRgab/c
lQl6Bj6ETaYTSY8Q2YjCR0ggL4qpYwO62fUexTB5aJx8JMpEbi0V3NZX/2xpic2m
27NW95j7oxi55Q36sYQNpFxfp9pIft6n3+RYTWIQ0bDV5O4W0TGAGPMDkH+t1K9x
ZZEoLik0aOfHw9sp96LkU5oZGGeWEGt6CmWHZQDiBSAyuTe6IjTpAgMBAAEwDQYJ
KoZIhvcNAQELBQADggEBAC4m+Lpl6pH45VGGvpaolL6PnL5TGcd7FL39C6DxL7Cl
MftcLuG6Egka+eJr/tg+6pdOFfpQjrkeDpeiRIABcLu/VrK99Te7c946QWc8QupC
G/VSQRIHOW6ReBsFf2/wrwT8MWDq2I2GAZSuZ9eTGWggQEwyem6y7C4ujtrcpixq
XwkeE2AU/91O2LlRrP/gW3hwEgD3VruMFhnm/3tTc7ZeLhJPSIE8EMhCk3+j2tgI
ta9J6NZClMxRLgBe1cOH2ru8eGsJtDnT2J+h0m/Ra3t9pD70Amoo84ytE3Iyui8i
kL2gg278c7PF5qosjPkp5sjjvWFypk8iYHTgTidbRCg=
-----END CERTIFICATE-----
subject=/C=GB/ST=Unknown/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=M. Manna
issuer=/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
---
Acceptable client certificate CA names
/C=GB/ST=Some-State/L=London/O=SOAPYSUDS/OU=SOAPYSUDS/CN=localhost/emailAddress=xyz#xyz.com
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 5048 bytes and written 285 bytes
Verification error: self signed certificate in certificate chain
---
New, TLSv1.0, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : ECDHE-RSA-AES256-SHA
Session-ID: 59884152B1D0B4716F30AC8E43BAC10EBBE92E6BD771AAAD31046035564F2B30
Session-ID-ctx:
Master-Key: 124F0A4796CCE67A696105F4F88798CFC31E76885DEDF3EB1F702EA565543462AB1CCC9B4E6D726BD7489C17ED77C744
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1502101842
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
Extended master secret: no
---
Even though the above has error in "Self-signed certificate verification" I think this is common if the CA cert is self signed. Possibly, it is working since SSL Handshake has written/read data.
I can confirm from kafka-topics command (also, server.log) that the topic "test_ssl" creation was successful. I hope it's not because of this underscore "_".
If there was a handshake issue, it would have been caught in the logs (I think, unless the logger is turned off), but it looks like my SSL config has been accepted correctly. Just wanted to know if I have missed something which I cannot quite spot here.
Note - I am not using any SSL/TLS with my Zookeeper. Also, because I am starting the TLS tests locally, I am using a common trust store for now (cacerts in jre/lib/security).
-- my client SSL config
advertised.listeners=SSL://localhost:9093
listeners=SSL://localhost:9093
security.protocol=SSL
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_client.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
-- my server SSL related properties
security.inter.broker.protocol=SSL
ssl.keystore.location=/kafka_2.10-0.10.2.1/config/kafka_server.jks
ssl.keystore.password=test1234
ssl.key.password=test1234
ssl.truststore.location=$java_path/jre/lib/security/cacerts
ssl.truststore.password=changeit
ssl.endpoint.identification.algorithm=HTTPS
ssl.secure.random.implementation=SHA1PRNG
ssl.client.auth=required
fraction of my server logs after startup (with SSL debug enabled):
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Using SSLEngineImpl.
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, called closeOutbound()
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
kafka-network-thread-0-ListenerName(SSL)-SSL-0, closeOutboundInternal()
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
[Raw write]: length = 7
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
0000Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
: 15Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
03Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
03 00Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
02 02Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
50*** ClientHello, TLSv1.2
I am not sure what configuration I am missing to get this working. I don't think there is anything wrong in my certificate import order since I have confirmed my methods by matching with instructions here.
Regards,
It was just one config - but I wish there was slightly longer explanation on the documentation for this - but still my bad.
documentation
ssl.endpoint.identification.algorithm
I set it to HTTPS - this means that my client will verify my Fully Qualified Domain Name FQDN against one of the following:
1) Common Name (CN)
2) Subject Alternative Name (SAN)
when I created my ceritificate, I was being polite and added my first and last name thinking "That's my first and last names". Since my original certificates didn't have either of the following:
1) localhost as CN
2) localhost as a DNS
The clients couldn't verify the broker's FQDN against the presented certificate's SAN/CN values. I believe this was the reason since I got it to work after issuing a new self-signed SAN certificate (and importing them into client trust store).

Receiving "javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException" while connecting to "https:" site

I am trying to connect to a "https://" site which supports "TLSv1" protocol and the following cipher suites,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 4096 bits
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 4096 bits
using Apache's httpclient (Java platform - JDK 1.7)
Its working fine in JDK1.8 (which has support for Cipher suites with DH parameters > 1024 bits)
But its failing in JDK 1.7 with the following exception,
main, handling exception: java.lang.ArrayIndexOutOfBoundsException: 64
%% Invalidated: [Session-1, TLS_DHE_RSA_WITH_AES_128_CBC_SHA]
main, SEND TLSv1 ALERT: fatal, description = internal_error
main, WRITE: TLSv1 Alert, length = 2
[Raw write]: length = 7
0000: 15 03 01 00 02 02 50 ......P
main, called closeSocket()
main, IOException in getSession(): javax.net.ssl.SSLException: java.lang.ArrayIndexOutOfBoundsException: 64
As suggested in the workaround here,
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=6521495,
I used tried using Bouncy Castle Provider but still getting the same exception.
Any help would be great. Thanks.
The issue is, you are using 2048 DH key with TLS v1 while its compatible with TLS v1.2, So you can resolve it by three ways:
1) Upgrade your JDK version to 1.8
2) Disable all DHE ciphers from server
3) Use 1048 DH key on server
for more details, see here

WSO2 ESB SSL handshake failure

I'm getting this error when trying to access a secure external service:
TID: [0] [ESB] [2016-01-07 11:08:52,310] ERROR - I/O error: General SSLEngine problem {org.apache.synapse.transport.passthru.TargetHandler}
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1364)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1197)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1169)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
at org.apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.java:154)
at org.apache.http.impl.nio.reactor.SSLIOSession.isAppInputReady(SSLIOSession.java:273)
at org.apache.http.impl.nio.ssl.SSLClientIOEventDispatch.inputReady(SSLClientIOEventDispatch.java:241)
at org.apache.http.impl.nio.reactor.BaseIOReactor.readable(BaseIOReactor.java:158)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvent(AbstractIOReactor.java:340)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.processEvents(AbstractIOReactor.java:318)
at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:278)
at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:104)
at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:542)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1703)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:278)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1338)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:154)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:808)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:806)
at java.security.AccessController.doPrivileged(Native Method)
at sun.security.ssl.Handshaker$DelegatedTask.run(Handshaker.java:1301)
at org.apache.http.impl.nio.reactor.SSLIOSession.doHandshake(SSLIOSession.java:171)
... 9 more
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:385)
at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:292)
at sun.security.validator.Validator.validate(Validator.java:260)
at sun.security.ssl.X509TrustManagerImpl.validate(X509TrustManagerImpl.java:326)
at sun.security.ssl.X509TrustManagerImpl.checkTrusted(X509TrustManagerImpl.java:283)
at org.apache.synapse.mediators.builtin.LogMediator.getFullLogMessage(LogMediator.java:184)
at org.apache.synapse.mediators.builtin.LogMediator.getLogMessage(LogMediator.java:123)
at org.apache.synapse.mediators.builtin.LogMediator.mediate(LogMediator.java:91)
at org.apache.synapse.mediators.AbstractListMediator.mediate(AbstractListMediator.java:71)
at org.apache.synapse.mediators.base.SequenceMediator.mediate(SequenceMediator.java:114)
at org.apache.synapse.core.axis2.Axis2SynapseEnvironment.injectMessage(Axis2SynapseEnvironment.java:230)
at org.apache.synapse.core.axis2.SynapseCallbackReceiver.handleMessage(SynapseCallbackReceiver.java:443)
at org.apache.synapse.core.axis2.SynapseCallbackReceiver.receive(SynapseCallbackReceiver.java:166)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:180)
at org.apache.synapse.transport.passthru.ClientWorker.run(ClientWorker.java:218)
at org.apache.axis2.transport.base.threads.NativeWorkerPool$1.run(NativeWorkerPool.java:172)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:722)
Caused by: com.ctc.wstx.exc.WstxEOFException: Unexpected end of input block; expected an identifier
at [row,col {unknown-source}]: [5,13]
at com.ctc.wstx.sr.StreamScanner.throwUnexpectedEOB(StreamScanner.java:691)
at com.ctc.wstx.sr.StreamScanner.loadMoreFromCurrent(StreamScanner.java:1057)
at com.ctc.wstx.sr.StreamScanner.getNextCharFromCurrent(StreamScanner.java:802)
at com.ctc.wstx.sr.BasicStreamReader.handleStartElem(BasicStreamReader.java:2917)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2814)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1062)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
at org.apache.axiom.util.stax.dialect.DisallowDoctypeDeclStreamReaderWrapper.next(DisallowDoctypeDeclStreamReaderWrapper.java:34)
at org.apache.axiom.util.stax.wrapper.XMLStreamReaderWrapper.next(XMLStreamReaderWrapper.java:225)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.parserNext(StAXOMBuilder.java:681)
at org.apache.axiom.om.impl.builder.StAXOMBuilder.next(StAXOMBuilder.java:214)
... 30 more
The certificate was successfully imported by keytool and it appears on "Available Certificates" list.
The supported protocols and ciphers of the endpoint service are:
Supported versions: TLSv1.0 TLSv1.1 TLSv1.2
Deflate compression: no
Supported cipher suites (ORDER IS NOT SIGNIFICANT):
TLSv1.0
RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
(TLSv1.1: idem)
TLSv1.2
RSA_WITH_3DES_EDE_CBC_SHA
RSA_WITH_AES_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA
RSA_WITH_AES_256_CBC_SHA
DHE_RSA_WITH_AES_256_CBC_SHA
RSA_WITH_AES_128_CBC_SHA256
RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
DHE_RSA_WITH_AES_128_CBC_SHA256
DHE_RSA_WITH_AES_256_CBC_SHA256
RSA_WITH_CAMELLIA_256_CBC_SHA
DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
----------------------
[...]
----------------------
Minimal encryption strength: strong encryption (96-bit or more)
Achievable encryption strength: strong encryption (96-bit or more)
BEAST status: vulnerable
CRIME status: protected
Seems like it's a bug on ESB when trying to perform the handshake.
I'm using the ESB-4.6.0
UPDATE
The certificate was imported by:
keytool -import -trustcacerts -alias MyService -file /tmp/myservice.crt -keystore wso2carbon.jks
According Tharik's suggestion, the SSL handshake trace prints the following error:
[...]
***
HTTPS-Sender I/O dispatcher-1, fatal error: 46: General SSLEngine problem
sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
%% Invalidated: [Session-8, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA]
HTTPS-Sender I/O dispatcher-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown
HTTPS-Sender I/O dispatcher-1, WRITE: TLSv1 Alert, length = 2
HTTPS-Sender I/O dispatcher-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: General SSLEngine problem
[2016-01-08 17:13:47,921] ERROR - TargetHandler I/O error: General SSLEngine problem
javax.net.ssl.SSLHandshakeException: General SSLEngine problem
at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1364)
at sun.security.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:513)
at sun.security.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1197)
at sun.security.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1169)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:469)
Problem solved.
In this case is that the ESB has a particularity which is a separated keystore for client-side operations. The correct import command is:
keytool -importcert -file <CERTIFICATE_FILE> -keystore <ESB_HOME>/repository/resources/security/client-truststore.jks -alias "SomeAlias"
In other words, the correct keystore is client-truststore.jks instead wso2carbon.jks.

javax.net.ssl.SSLHandshakeException: handshake_failure when using JMeter with SSL (JDK8)

I am writing a JMeter test plan to connect to SSL port (Tomcat Connector). I receive a SSLHandshakeException (handshake_failure) when connecting to SSL port using any of the three JMeter SSL client implementations (HttpClient4, HttpClient3.1, Java) on JDK8 (1.8.0_51). If I use JDK7 (1.7.0_75) - everything works as expected.
Client JDK: HotSpot 1.8.0_51
Client OS: Mac OSX 10.10.2
JMeter version: 2.13
Server: Tomcat 7.0.63 (latest)
Server SSL CipherSuite: RC4-SHA
Server SSL Protocol: all
Server Java: OpenJDK 1.7.0_79
Here are some things I have already tried:
(1) I tried replacing the JCE Unlimited Strength JARs, as suggested on a similar question:
SSLHandshakeException while connecting to a https site
No changes in error messages or logfile, JDK8 client would not connect to the SSL server.
(2) I turned on debugging as described here: https://blogs.oracle.com/java-platform-group/entry/diagnosing_tls_ssl_and_https. Starting JMeter with JVM_ARGS set to -Djavax.net.debug=ssl:handshake:verbose. The logfile (attached below) did not hint any reasons what the issue might be.
(3) I tried specifying the HTTPS procotol, e.g. -Dhttps.protocols=SSLv3. No luck. SSLv3 was disabled or cipher were not matching:
javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
(4) I tried disabling SNI, e.g. -Djsse.enableSNIExtension=false. No luck either.
So, I am forced to use the JDK7 for now, until I can get my JMeter to run with JDK8, and I'd like to fix that.
So, the issue is in how JDK8 handles SSL clients differently from JDK7. Also, the server (Tomcat Connector) would need to support appropriate ciphers and protocols, but that's out of my control for now.
Here are relevant logs:
X509KeyManager passed to SSLContext.init(): need an X509ExtendedKeyManager for SSLEngine use
trigger seeding of SecureRandom
done seeding SecureRandom
Agents (clients) 1-2, setSoTimeout(0) called
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
%% No cached client session
*** ClientHello, TLSv1.2
RandomCookie: *** ClientHello, TLSv1.2
GMT: 1422637724 bytes = { RandomCookie: GMT: 1422637724 bytes = { 71, 27, 101, 246, 26, 99, 64, 213, 53, 66, 156, 66, 118, 137, 247113, , 226, 86, 121, 189, 207, 175, 98, 46, 64, 242, 48, 19, 30, 66, 251, 120, 125, 249, 63, 114, 254, 246, 5, 168, 17, 190, 214, 228, 90, 165128 }
Session ID: , 113, {}
157, 211, 230, 144, Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
145, 63, Compression Methods: { 238, 0178 }
Session ID: {}
}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, secp384r1, sect409k1, sect409r1, secp521r1, sect571k1, sect571r1, secp160k1, secp160r1, secp160r2, sect163r1, secp192k1, sect193r1, sect193r2, secp224k1, sect239k1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA224withECDSA, SHA224withRSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA, MD5withRSA
***
Agents (clients) 1-2, WRITE: TLSv1.2 Handshake, length = 237
Agents (clients) 1-1, WRITE: TLSv1.2 Handshake, length = 237
Agents (clients) 1-2, READ: TLSv1.2 Alert, length = 2
Agents (clients) 1-2, RECV TLSv1.2 ALERT: fatal, handshake_failure
Agents (clients) 1-2, called closeSocket()
Agents (clients) 1-2, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Agents (clients) 1-2, called close()
Agents (clients) 1-2, called closeInternal(true)
Agents (clients) 1-1, READ: TLSv1.2 Alert, length = 2
Agents (clients) 1-1, RECV TLSv1.2 ALERT: fatal, handshake_failure
Agents (clients) 1-1, called closeSocket()
Agents (clients) 1-1, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
Agents (clients) 1-1, called close()
Agents (clients) 1-1, called closeInternal(true)
Here's the stacktrace I get in JMeter logfile:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:2023)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1125)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1375)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1403)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1387)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:563)
at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:185)
at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:153)
at org.apache.jmeter.protocol.http.sampler.HTTPJavaImpl.sample(HTTPJavaImpl.java:483)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerProxy.sample(HTTPSamplerProxy.java:74)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1146)
at org.apache.jmeter.protocol.http.sampler.HTTPSamplerBase.sample(HTTPSamplerBase.java:1135)
at org.apache.jmeter.threads.JMeterThread.process_sampler(JMeterThread.java:434)
at org.apache.jmeter.threads.JMeterThread.run(JMeterThread.java:261)
at java.lang.Thread.run(Thread.java:745)
So, how do I make JDK8 client in JMeter talk to SSL port using protocols and ciphers allowed by the server.
Thanks!
Edit: Added SSL Labs test results
Protocols
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
Cipher Suites (sorted by strength as the server has no preference; deprecated and SSL 2 suites at the end)
TLS_RSA_WITH_RC4_128_SHA (0x5) WEAK 128
Clients
Java 6u45 No SNI 2 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5) No FS RC4 128
Java 7u25 TLS 1.0 TLS_RSA_WITH_RC4_128_SHA (0x5) No FS RC4 128
Java 8u31 TLS 1.2 TLS_RSA_WITH_RC4_128_SHA (0x5) No FS RC4 128
So after some digging, and ideas in the comments, it boils down to the Tomcat configuration. Tomcat Configuration only allowed RC4-SHA, which is insecure and not supported in Java 8 anymore, per RFC7465 (thanks Robert for the reference).
I got JMeter to work on Java8, by updating server SSL configuration and removing RC4-SHA-only cipher, and allowing all default cipher suites, e.g. dropping SSLCipherSuite="RC4-SHA" from server.xml Tomcat configuration file.
Adding stronger security encryption (JCE Unlimited Strength Policy), will allow for better cipher suites and stronger encryption. You will need to be aware of US exporting rules though.
I will need to make decision as to which ciphers we want to support. That depends on the clients that we are expecting to connect to our SSL Tomcat connector. One client is definitely our JMeter test client, and there are few other RESTful clients that will be connecting, written in various languages and for various platforms.
Hopefully this discussion helps out others and shed some light.
I would like to edit this answer to add recommended (at the moment) TLS protocol and CipherSuite settings.
I found some great discussion on Mozilla ServerSide SSL Configuration:
Modern Compatibility
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
Versions: TLSv1.1, TLSv1.2
RSA key size: 2048
DH Parameter size: 2048
Elliptic curves: secp256r1, secp384r1, secp521r1 (at a minimum)
Certificate signature: SHA-256
HSTS: max-age=15724800
Intermediate Compatibility
Ciphersuite: ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
Versions: TLSv1, TLSv1.1, TLSv1.2
RSA key size: 2048
DH Parameter size: 2048 (see DHE and Java for details)
Elliptic curves: secp256r1, secp384r1, secp521r1 (at a minimum)
Certificate signature: SHA-256
... and others
Thanks everyone that chimed in.
Here's how I solved this problem on a mac, as gleaned from here on StackOverflow:
Download updated security jars from Oracle - these ones are for Java 8:
http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html
Unzip the downloaded zip file.
Go to the security folder in your java home directory:
cd $(/usr/libexec/java_home)/jre/lib/security
Back up the following jars from this folder:
US_export_policy.jar
local_policy.jar
Replace with jars from zip file.
Restart Jmeter.
I was getting same exception in JDK7_u80. javax.net.ssl.SSLHandshakeException: handshake_failure. Even after I replace jars in security folders with JCE jar.
I installed new version JDK8_u92 and set the environment path to newly installed Java8. And jmeter issue is resolved now.
I was facing the same issue and resolved it based on the inputs given in the above post. My two cents in resolving the issue:
Try to hit the URL from chrome and click on lock button and view certificate.
Look for the https protocol supported (e.g. TLS v1.2)).
Verify from if your java version supports. If not, update java.
In jmeter properites file, update the property to
https.default.protocol=TLSv1.2
Restart jmeter.
The above procedure worked for me.
There is a solution that allows JMeter to connect to insecure endpoints (or those that use old or not secured enough protocols):
Find your JRE;
Open jre\lib\security\ folder;
Make a backup copy of java.security file;
Edit java.security file and comment out all lines that disable insecure algorithms - search for 'disabledAlgorithms' string (don't forget to comment out both lines in multiline settings), they look like:
jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
DSA keySize < 1024, EC keySize < 224
save the file and restart JMeter.
Java connections are now allowed to use old protocols, so JMeter can properly work.
REMEMBER it's security!
These settings are global, and will affect all programs that use the same JRE. If you found this fix works and useful for your system, DO create a copy of your JRE, and set a path to it in jmeter.bat. Return your global settings from backed up copy of java.security file.
I was having similiar issue with Jmeter 3.2 and JRE 8 and add below properties in Jmeter JNDI Properties, its working fine for me:
java.naming.security.principal
java.naming.security.credentials
com.tibco.tibjms.naming.security_protocol
com.tibco.tibjms.naming.ssl_enable_verify_host
com.tibco.tibjms.naming.ssl_trusted_certs
com.tibco.tibjms.naming.ssl_password
com.tibco.tibjms.naming.ssl_auth_only
com.tibco.tibjms.naming.ssl_trace
com.tibco.tibjms.naming.ssl_debug_trace
com.tibco.tibjms.naming.ssl_identity

Red5 and RTMPS self-signed certificate

I am trying to configure rtmps using self-signed certificate, but when I try to connect via red5pfone I get an error:
*** ServerHelloDone
NioProcessor-2, WRITE: TLSv1 Handshake, length = 890
NioProcessor-2, READ: TLSv1 Alert, length = 2
NioProcessor-2, RECV TLSv1 ALERT: fatal, unknown_ca
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unknown_ca
NioProcessor-2, fatal: engine already closed. Rethrowing javax.net.ssl.SSLException: Received fatal alert: unknown_ca
[WARN] [NioProcessor-2] org.red5.server.net.rtmps.RTMPSMinaIoHandler - Exception caught SSL handshake failed.
Red5-0.9.1
Red5Phone-R47
I tried to follow the directions from here:
http://gregoire.org/2008/05/26/rtmps-in-red5/ and http://www.cb1inc.com/2007/05/12/creating-self-signed-certs-on-apache-tomcat-5-5/ but it did not give results.
Please help.
Self-signed certs are really difficult to use with Flash and should be avoided. I would assume that you are using "localhost", but if you are trying to access this from an external location I would suggest getting a real CA-signed certificate (there are free ones out there) and testing with that on your domain. Versions of Red5, 1.0 or greater have better support for certs, crossdomain, and ip binding; I suggest you start with one of them.