I'm building a java-ee application which should connect to an iCal CalDAV server using SSL.
I get this error every time I try to connect to the server.
javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
With other tools it worked fine, even with java tools after importing the certificate into the truststore.
If I try to connect using TLS I get a response that says, the server only supports SSLv3.
heres how I investigated the SSL handshake with the openssl tool
openssl s_client -host kalender.myserver.com -port 8443
this is what i get:
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.myserver.com
i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
2 s:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
---
Server certificate
[[certificate]]
subject=/OU=Domain Control Validated/CN=*.myserver.com
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
---
SSL handshake has read 3422 bytes and written 565 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : AES256-SHA
Session-ID: 99D28660004D122D20657883562319F4F3063B1123AC882AD722B781EB13FF45
Session-ID-ctx:
Master-Key: 6228C28941D81771C68F0FA5546491804081294A95F4A2BE19AC239CF47C24752AC350F54BAEDD3C8E4A7E1044B4B429
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1406820530
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
when i try
openssl s_client -tls1 -host kalender.myserver.com -port 8443
this appears and the connection fails:
CONNECTED(00000003)
139883471566496:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 7 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1407752794
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Here's how I investigated the SSL handshake with a Java tool I found here.
I modified it so i can use another port.
to google:
java HTTPSClient google.com --> does not throw an exception
to my server on port 8443:
SSLv3: no error
TLSv1: javax.net.ssl.SSLHandshakeException: Server chose SSLv3, but that protocol version is not enabled or not supported by the client.
I drew the conclusion that the server only supports SSLv3, so I tried to get my app to do that too, using a HttpClient provided by apache but it does not seem to be compatible.
That means I have to say my app to use SSLv3, too. That would be somewhere in the org.osaf.caldav4j.methods.HttpClient class which inherits from org.apache.commons.httpclient.HttpClient. The problem is, I can't find any way to do so.
I tried
System.setProperty("https.protocols", "SSLv3");
and
httpClient.getParams().setParameter("https.protocols", "SSLv3");
but neither of them makes a difference. I also tried to somehow insert a custom SSLSocketFactory into the HTTPClient but found no way to do that. Here is the code to build the HTTPClient:
public HttpClient getHttpClient(String host, int port, String user, String password){
System.setProperty("https.protocols", "SSLv3");
org.apache.commons.httpclient.HttpClient httpClient = new HttpClient();
String protocol = "https";
String baseDir = "/calendars/users/" + user + "/calendar/";
httpClient.getHostConfiguration().setHost(host, port, protocol);
Credentials httpCredentials = new UsernamePasswordCredentials(user, password);
httpClient.getState().setCredentials(AuthScope.ANY, httpCredentials);
httpClient.getParams().setAuthenticationPreemptive(true);
httpClient.getParams().setParameter("https.protocols", "SSLv3");
return (HttpClient) httpClient;
}
And this is the stack trace i get when i try to connect (i cut off the java-ee internal stuff):
Caused by: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac
at sun.security.ssl.Alerts.getSSLException(Alerts.java:208)
at sun.security.ssl.Alerts.getSSLException(Alerts.java:154)
at sun.security.ssl.SSLSocketImpl.recvAlert(SSLSocketImpl.java:1959)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1077)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:702)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at org.apache.webdav.lib.methods.HttpRequestBodyMethodBase.writeRequestBody(HttpRequestBodyMethodBase.java:235)
at org.apache.webdav.lib.methods.XMLResponseMethodBase.writeRequestBody(XMLResponseMethodBase.java:303)
at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2114)
at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
at org.osaf.caldav4j.methods.HttpClient.executeMethod(HttpClient.java:103)
at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:346)
at org.osaf.caldav4j.CalDAVCollection.getCalDAVResources(CalDAVCollection.java:1029)
... 86 more
Problem solved with just one line of code.
System.setProperty("com.sun.net.ssl.rsaPreMasterSecretFix", "true");
If I understand it right, I need this to tell Java to use the maximum supported version of SSL/TLS instead of some weird other one. You can check it here. Anyways thanks for your help!
Related
We are running our Java Application on RHEL 8.5 OS platform. In our Apache's ssl.conf file, we have enabled only TLSv1.2 protocol. And we are not using TLSv1 and TLSv1.1 protocols in our application.
From the below details, it is confirmed that the above protocols are disabled from an OS perspective also.
update-crypto-policies --show
DEFAULT
From RHEL, it is confirmed that "The TLS versions TLS 1.0 and TLS 1.1 protocols are disabled in the DEFAULT system-wide cryptographic policy level. "
And from the below command results, it is confirmed that TLS 1.0 and TLS 1.1 is disabled from the Application Side.
[root#test ~]# openssl s_client -connect <IP_ADDRESS>:8443 -tls1
CONNECTED(00000003)
139679030896448:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:ssl/record/rec_layer_s3.c:1544:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 104 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1662128840
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
-----------------------------------------
[root#test ~]# nmap -sV --script ssl-enum-ciphers -p 8443 <IP_ADDRESS>
Starting Nmap 7.70 ( https://nmap.org ) at 2022-09-20 20:02 IST
mass_dns: warning: Unable to open /etc/resolv.conf. Try using --system-dns or specify valid servers with --dns-servers
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for XXXXX (IP_ADDRESS)
Host is up (0.00067s latency).
PORT STATE SERVICE VERSION
8443/tcp open ssl/http Apache httpd
|_http-server-header: Apache
| ssl-enum-ciphers:
| TLSv1.2:
| ciphers:
| TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
| TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
| compressors:
| NULL
| cipher preference: client
|_ least strength: A
MAC Address: 00:50:56:A7:92:7B (VMware)
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 12.90 seconds
-----------------------------------------
Please find the configurations on "ssl.conf",
SSLProtocol -ALL +TLSv1.2
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:AES256-CCM:DHE-RSA-AES256-CCM
But we are in confusion that why the Nessus scan vulnerability shows the TLS 1.0 and TLS 1.1 protocols even though those 2 protocols are disabled in all possibilities.
Vulnerability Details are listed below,
104743 TLS Version 1.0 Protocol Detection
157288 TLS Version 1.1 Protocol Deprecated
From Nessus team, we came to know that port 4567 is using the below ciphers,
TLS1_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS1_DHE_DSS_WITH_AES_256_CBC_SHA256
TLS1_CK_DHE_DSS_WITH_AES_128_CBC_SHA
TLS1_CK_DHE_DSS_WITH_AES_256_CBC_SHA
TLS1_CK_DHE_DSS_WITH_3DES_EDE_CBC_SHA
In our application, we are using port 4567 as TRUSTSTORE_PORT where it is downloading the required certificates for the application to run.
But we enabled only the TLSv1.2 protocol. How the TLS1 ciphers are enabled?
Please let me know how to overcome these vulnerabilities.
Thanks in Advance.
I've suddenly been getting these errors when making HTTP requests:
Caused by: javax.net.ssl.SSLHandshakeException: Remote host closed connection during handshake
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1002)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1385)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1413)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1397)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:290)
at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:259)
at org.apache.http.impl.conn.HttpClientConnectionOperator.connect(HttpClientConnectionOperator.java:125)
at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:319)
at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:363)
at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:219)
at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195)
at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:86)
at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108)
at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:184)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106)
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:57)
at com.mashape.unirest.http.HttpClientHelper.request(HttpClientHelper.java:138)
... 24 more
Caused by: java.io.EOFException: SSL peer shut down incorrectly
at sun.security.ssl.InputRecord.read(InputRecord.java:505)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:983)
... 41 more
It didn't always do this, it was working fine for awhile. I then used different libraries and even a different IntelliJ project for testing, still the same issues. Things I've tried:
Changing the endpoint I'm using
Setting the TLS version to TLSv1.2 (as I found when making a browser request)
I can load the endpoint fine with a browser and Postman. My code (using the Unirest library):
System.setProperty("https.protocols", "TLSv1.2");
System.out.println(Unirest.get("https://bittrex.com/api/v1.1/public/getmarketsummary?market=btc-ltc").asString().getBody());
I'm at a loss as to what could be causing this issue, and it's extremely frustrating. Any help would be appreciated.
EDIT: Updating to JDK10 fixed the issue. See the chosen answer and it's comment thread for more info.
First, turn on SSL debug: -Djavax.net.debug=all
Redirect your code's stdout to a file and check it for errors around handshaking.
If you examine the url you use with nmap or openssl:
nmap --script ssl-enum-ciphers -p <port> <host>
or
openssl s_client -connect <host>:<port>
(host: bittrex.com, port: 443)
you can see that is uses TLSv1.2 and ECDHE-ECDSA-AES128-GCM-SHA256 cypher:
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-GCM-SHA256
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-ECDSA-AES128-GCM-SHA256
Depending on your JDK version, you may need to install JCE extension and/or specify this cypher.
To be sure, you should print out the current supported cyphers using this little java code. If ECDHE-ECDSA-AES128-GCM-SHA256 not listed, this is your problem.
I'm facing issue connecting to LDAPS from my application. I have imported all necessary certificates on JRE keystore.
I'm able to make calls to LDAPs when I put the following string in java.security
jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
When I change this line to
jdk.tls.disabledAlgorithms=MD5, DSA, DESede, DES_CBC, DHE, RC4, SSLv3, ECDH_anon, DH_anon, NULL, DH keySize < 768, RSA keySize < 2048
my connection fails with following error:
Caused by: javax.naming.CommunicationException: simple bind failed: testxxxxl.xxxx.com:636 [Root exception is java.net.SocketException: Socket closed]
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:218)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193)
at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211)
at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84)
at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:122)
... 72 more
Caused by: java.net.SocketException: Socket closed
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:152)
at java.net.SocketInputStream.read(SocketInputStream.java:122)
at sun.security.ssl.InputRecord.readFully(InputRecord.java:442)
at sun.security.ssl.InputRecord.read(InputRecord.java:480)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:934)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1332)
at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:709)
at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82)
at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:431)
at com.sun.jndi.ldap.Connection.writeRequest(Connection.java:404)
at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:358)
In wireshark it complains about certificate invalid.My question is if my certificate is invalid, it shouldn't be working with this line as well.
jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
Please help me to solve the issue.
If you use a secure connection to the LDAP server and you see an error like the following when trying to connect to Active Directory:
simple bind failed: ad.hostname.com:636
Import the LDAP server public certificate directly into the Klocwork keystore (which should be_jvm\lib\security\cacerts).
This causes the certificate validation process at the Klocwork end to be bypassed, since you have decided to trust the LDAP server certificate by importing it into your list of trusted certificates.
Ask your LDAP administrator to set this extension of your LDAP server certificate to non-critical.
In recent versions of Java the TLSv1 has been disabled.
In my case this happened when upgrading from Java 8 to Java 11.
Re-enabling TLSv1 helped. It is as easy as defining property:
-Djdk.tls.client.protocols=TLSv1
Of course you can need also other protocols, so you can specify full list:
-Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2,TLSv1.3
MobileFirst 7.1.0.00-20150807-0630
Java 1.7.0_80
I have a Java adapter that connects to a backend service using REST. at macm.saas.ibmcloud.com:443. All works fine from a Development server. But when I deploy it to a production server (both on-prem and a Bluemix Container), I get the following error when the adapter attempts to connect to the server:
javax.net.ssl.SSLHandshakeException: No negotiable cipher suite
I would think the problem is related to how the keystore is configured, but I don't understand why it would be different on a prod server than the dev server.
Running openssl s_client -connect macm.saas.ibmcloud.com:443 gives me:
> CONNECTED(00000003)
depth=2 /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
verify error:num=19:self signed certificate in certificate chain
verify return:0
---
Certificate chain
0 s:/C=US/ST=New York/L=Armonk/O=International Business Machines Corporation/CN=macm.saas.ibmcloud.com
i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
2 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGWzCCBUOgAwIBAgIQATFWvLyURadTLNafH0mf0zANBgkqhkiG9w0BAQsFADBN
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E
aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTUxMDA3MDAwMDAwWhcN
MTgxMDExMTIwMDAwWjCBiDELMAkGA1UEBhMCVVMxETAPBgNVBAgTCE5ldyBZb3Jr
MQ8wDQYDVQQHEwZBcm1vbmsxNDAyBgNVBAoTK0ludGVybmF0aW9uYWwgQnVzaW5l
c3MgTWFjaGluZXMgQ29ycG9yYXRpb24xHzAdBgNVBAMTFm1hY20uc2Fhcy5pYm1j
bG91ZC5jb20wggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCrxABCsOK4
8j1lshwGxBWJSVXSR1sM4PvyLo0v2p7LMVmsX81jWV67P6+NxvnfQFRr4WqpUbxZ
SPtx37ykO9Non4dFry6USvt22RwA31yveSlpzKaicdZqK8zr5DiQs5SSGvt+6tHb
KgNjwPRWjphaT6C3V2s1yUfwPSQvcrnv9jIgx3dvpFgfJ4SyJ8cBxyGZnp1MsVZX
4hgNgLeFRXdoq6708leLPI9x/f+uQvzUqPZqPOIz3piUzncCSQVE9WkGAQkU2BCe
9xR9hFuIcPgHoiEfHozHPOcg/fKChWwSb3FBJIVOXvoVSPADnzNxqSOA84B3PYNP
T9iJ7Mu5qSOMZLo+JBknKQXUdTxh/yUw0E2QikkgE1DBOSjnVPTNgqveR/CHr67N
1S/pvXVpYUAxmfxt2XFc9Qqo7cMJDTBvoR/93tkIUOevyAhcLbkS8QH+Yn/u7WWp
1h13OtYudtnPDUAElRrf5nty2j01u6uH7jF/ZkMeZbNjjV56Rrwh3uWwe05fgRGV
MeTEc4ccq9b/BUb5K0BCI0AFd2B2ZYOqOnfnvKuQybIrUNpHf+A5su6mzM14FdQY
lJ6vXRa7rzKT4/UH3xiYf7qzpi3h3iBFJ9EcEk6F1W+9I/X6bfbXqjJU8QHGWpYR
ceMXdKLZWuLxQC3+g7pqep5bGjxGye1LGwIDAQABo4IB+TCCAfUwHwYDVR0jBBgw
FoAUD4BhHIIxYdUvKOeNRji0LOHG2eIwHQYDVR0OBBYEFE8uz2MkSduo1sHr/F43
PRBkscnPMD0GA1UdEQQ2MDSCFm1hY20uc2Fhcy5pYm1jbG91ZC5jb22CGnd3dy5t
YWNtLnNhYXMuaWJtY2xvdWQuY29tMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwawYDVR0fBGQwYjAvoC2gK4YpaHR0cDovL2Ny
bDMuZGlnaWNlcnQuY29tL3NzY2Etc2hhMi1nNC5jcmwwL6AtoCuGKWh0dHA6Ly9j
cmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLXNoYTItZzQuY3JsMEwGA1UdIARFMEMwNwYJ
YIZIAYb9bAEBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNv
bS9DUFMwCAYGZ4EMAQICMHwGCCsGAQUFBwEBBHAwbjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AuZGlnaWNlcnQuY29tMEYGCCsGAQUFBzAChjpodHRwOi8vY2FjZXJ0
cy5kaWdpY2VydC5jb20vRGlnaUNlcnRTSEEyU2VjdXJlU2VydmVyQ0EuY3J0MAwG
A1UdEwEB/wQCMAAwDQYJKoZIhvcNAQELBQADggEBAIWJCItCBT0mE53OjwMdJsq0
nGgrMfb7LbF+5exdtqqaKyq8Zuke3yEbFv4nRg3LUcmh8HMLn8gSDTCnVRH0BCLx
OBmxgRVRm7eXTVSiE8tbdMOHbUEdu96MUSppSCW8CfLMAr3kPnyMWlCPgg215fn2
72CM6m3n9AKEJXcwFRmhriNiSsVeKlTqW+5efqHUig8QOmzqJTo03M2gH/jRY1Au
Dr2nPzyVYxoztBWtlC1ECfSCUbiF0URYXCJbI+UbyQCB8C+k+ikn5H/95Ingvg2v
pmLquKDFH9iH022wA/UaVeQ+AqzXcEQZgfEq+U4ZQNIRJ+ae5KDFwQS+E7OpmR4=
-----END CERTIFICATE-----
subject=/C=US/ST=New York/L=Armonk/O=International Business Machines Corporation/CN=macm.saas.ibmcloud.com
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3919 bytes and written 712 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : AES128-SHA
Session-ID: 21D5000057760A8FE4AB39A6388838B6F38A523A58585858079454560000F4B0
Session-ID-ctx:
Master-Key: 82C926729FA56D9FD83E357C3B6FD372D587D73E8FC28E3721BE053A4CD6CDA45949AD4F03EF2759DEE882B1FFEF257E
Key-Arg : None
Start Time: 1448383495
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
I eventually rewrote the Java connection code using a different set of libraries that worked for an app written by another team. I never did determine what it was about my code that did not work, but it appears to have been specific to the way I attempted to implement it.
I created a server in Java (Android) with SSLServerSocket with a self-signed certificate and i am trying to connect to the server with wget:
wget https://myAndroidserver:8080 -v --ca-certificate=client.pem --no-check-certificate
but it gives the following error:
OpenSSL: error: 14094410: SSL routines: SSL3_READ_BYTES: SSLv3 handshake failure alert
The following error is logged in my Java application:
error: 140890C7: SSL routines: SSL3_GET_CLIENT_CERTIFICATE: peer did not return a certificate (external/openssl/ssl/s3_srvr.c: 3271 0x5926f79c: 0x00000000)
How to solve it?
If I am reading your question correctly....
**server**:
OpenSSL: error: 14094410: SSL routines: SSL3_READ_BYTES: SSLv3 handshake failure alert
**client**:
error: 140890C7: SSL routines: SSL3_GET_CLIENT_CERTIFICATE: peer did not return a certificate (external/openssl/ssl/s3_srvr.c: 3271 0x5926f79c: 0x00000000)
SSL/TLS is not running on the server at port 8080; or its not serving a certificate.
You can also use OpenSSL's s_client with the -state flag to verify the messages sent and received:
$ openssl s_client -connect encrypted.google.com:443 -state
CONNECTED(00000003)
SSL_connect:before/connect initialization
SSL_connect:SSLv2/v3 write client hello A
SSL_connect:SSLv3 read server hello A
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
SSL_connect:SSLv3 read server certificate A
SSL_connect:SSLv3 read server key exchange A
SSL_connect:SSLv3 read server done A
SSL_connect:SSLv3 write client key exchange A
SSL_connect:SSLv3 write change cipher spec A
SSL_connect:SSLv3 write finished A
SSL_connect:SSLv3 flush data
SSL_connect:SSLv3 read server session ticket A
SSL_connect:SSLv3 read finished A
There's also a -debug flag, but its very verbose and hard to decode. If you are going to perform debug traces, you might as well use Wireshark since it breaks out all the fields in the messages.
Thanks for availability to help.
To resolve the issue follow the steps on this website click here to create the keystore and all file necessary to client and server, and used the bcprov-jdk16-1.45.jar to create keystore (bks) and used this command on client(wget):
wget https://myserver:port --certificate=client.pem --no-check-certificate --private-key=client_key.pem