How to enable communication over TLS1.2 on AIX 7.1 or 7.2 with IBM JDK 1.8 latest update?
By default, the request is trying to establish a connection over TLSv1 even though TLS 1.2 is explicitly enabled on server as well as on Java 8. The openssl command throws SSL handshake error. We tried with 2 versions of OpenSSL, 1.0.1e and 1.0.2k, but same behavior.
logs:
[06:24 AM root#s822-aix01p1 /opt]: openssl s_client -tls1_2 -connect 10.225.120.125:8443
CONNECTED(00000003)
804401144:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert internal error:s3_pkt.c:1259:SSL alert number 80
804401144:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:599:
no peer certificate available
No client certificate CA names sent
SSL handshake has read 7 bytes and written 0 bytes
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1550489753
Timeout : 7200 (sec)
Verify return code: 0 (ok)
It seems there is no cipher suites on common which can work for TLS 1.2.
Also, is there any way to enable TLS 1.1 & 1.2 in AIX? I have read few articles and got to know that these are not enabled by default on AIX.
You might have forgotten using this option:
-Dhttps.protocols=TLSv1.2
Or from code, at startup
System.setProperty("https.protocols", "TLSv1.2");
Related
I'm receiving the following SSL error on my rake rspec unit tests when I try to connect to the vault on my docker container using HTTPS:
OpenSSL::SSL::SSLError:
SSL_connect returned=1 errno=0 state=error: wrong version number
We're using docker to load a local instance of a hashicorp vault
Here's the command I run to generate the TLS Certificates
RUN openssl req -new -newkey rsa:4096 -x509 -sha256 -days 365 -nodes -subj "$SUBJ" -out /vault/certificates/tls/vault.crt \
-keyout /vault/certificates/tls/vault.key
When I log into the docker container and run openssl version I get:
/ # openssl version
OpenSSL 1.1.1k 25 Mar 2021
When I try to connect to the docker container from my local prompt, I get:
$ openssl s_client -connect 'localhost:8200'
CONNECTED(000001F0)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1620224762
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
26612:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:827:
When I run this command in my local irb I get:
irb(main):001:0> require 'openssl'
=> true
irb(main):002:0> OpenSSL::SSL::SSLContext::DEFAULT_PARAMS
=> {:min_version=>769, :verify_mode=>1, :verify_hostname=>true, :options=>2147614804}
irb(main):003:0>
This is my vault configurations:
listener "tcp" {
address = "[::]:8200"
cluster_address = "[::]:8201"
tls_cert_file = "/vault/certificates/tls/vault.crt"
tls_key_file = "/vault/certificates/tls/vault.key"
}
Also, i noticed in the docker logs we have two listeners now:
Listener 1: tcp (addr: "0.0.0.0:1234", cluster address: "0.0.0.0:1235", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled")
Listener 2: tcp (addr: "[::]:8200", cluster address: "[::]:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "enabled")
And my docker vault server startup command is:
vault server -config=/vault/config -dev-root-token-id=myroot -dev-listen-address=0.0.0.0:1234 -dev &
And i noticed in the logs its still seeing an http connection...
Error writing data to pki/root/generate/internal: Put https://127.0.0.1:1234/v1/pki/root/generate/internal: http: server gave HTTP response to HTTPS client
Error writing data to pki/config/urls: Put https://127.0.0.1:1234/v1/pki/config/urls: http: server gave HTTP response to HTTPS client
Error writing data to pki/roles/localhost: Put https://127.0.0.1:1234/v1/pki/roles/localhost: http: server gave HTTP response to HTTPS client
Error writing data to pki/issue/localhost: Put https://127.0.0.1:1234/v1/pki/issue/localhost: http: server gave HTTP response to HTTPS client
I'm kind of lost right now on how to handle this.
I'm using go http client to connect to iot device which has self-signed cert. I already have
TLSClientConfig: &tls.Config{
RootCAs: certPool,
Certificates: []tls.Certificate{tlsClientCert},
InsecureSkipVerify: true,
},
Nevertheless although InsecureSkipVerify=true go still tries to verify the certificate:
x509: cannot validate certificate for <ip> because it doesn't contain any IP SANs
As I can't change the cert on the device- what part of the TLS client config can I modify to accept it?
UPDATE
The go error can be reproduced running https://github.com/jbardin/gotlsscan/blob/master/main.go against the device:
Testing TLS1.2
...
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA [NOT SUPPORTED]
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 [NOT SUPPORTED] x509: cannot validate certificate for 192.168.1.145 because it doesn't contain any IP SANs
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 [NOT SUPPORTED]
...
This is what openssl says when running openssl s_client -connect <ip:port>:
CONNECTED(00000003)
depth=0 C = DE, O = Bebro, OU = ULK High GEN 1, CN = ICCPD...
verify error:num=18:self signed certificate
verify return:1
depth=0 C = DE, O = Bebro, OU = ULK High GEN 1, CN = ICCPD...
verify return:1
4460842604:error:1401E410:SSL routines:CONNECT_CR_FINISHED:sslv3 alert handshake failure:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.140.1/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
4460842604:error:1401E0E5:SSL routines:CONNECT_CR_FINISHED:ssl handshake failure:/AppleInternal/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-47.140.1/libressl-2.8/ssl/ssl_pkt.c:585:
---
Certificate chain
0 s:/C=DE/O=Bebro/OU=ULK High GEN 1/CN=ICCPD...
i:/C=DE/O=Bebro/OU=ULK High GEN 1/CN=ICCPD...
---
Server certificate
-----BEGIN CERTIFICATE-----
MII...
-----END CERTIFICATE-----
subject=/C=DE/O=Bebro/OU=ULK High GEN 1/CN=ICCPD...
issuer=/C=DE/O=Bebro/OU=ULK High GEN 1/CN=ICCPD...
---
No client certificate CA names sent
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 969 bytes and written 178 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-ECDSA-AES128-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-SHA256
Session-ID: 9C7D...
Session-ID-ctx:
Master-Key: AC9E...
Start Time: 1600892515
Timeout : 7200 (sec)
Verify return code: 18 (self signed certificate)
---
UPDATE I'm running latest go 1.15.2
This might work,
In certificate there is a field called "SANs", we need to add 'hostname' in this SAN list.
once this is added the same name should be added in TLS configuration using "ServerName" filed. after this configuration this will be resolved. In SANS property I've added "test.com" so I configured TLS as follows,
ServerName: "test.com",
RootCAs: pool,
Certificates: []tls.Certificate{clientCert},
MinVersion: tls.VersionTLS12,
Since the certificate you;re using may not contain any SANs, this error is occurred. I'm still exploring on it, If you guys any comments on this ,kindly leave a reply.
I'm trying to set up SSL certs for my laravel API so it can connect to my front end project. I'm hosting my server on aws EC2 so Ive been trying to use cloudfront and acm. I get a 502 error when trying to access my api routes using my DNS. In the error code cloud front sends a link and it tells me to use an open ssl command to determine if cloudfront can establish a connection. the command is
openssl s_client –connect domainname:443 –servername domainname
Once I add that with my domain name I get this response.
CONNECTED(00000003)
140306801927832:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 326 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1536682031
Timeout : 300 (sec)
Verify return code: 0 (ok)
---
Im not really sure where to go from here because this is my first time trying to set up ssl.
I know there are lots of discussion regarding this error but sorry to say that I'm unable to find any working solution over there.
I'm developing a ecommerce site using ShareTribe.I'm trying to implement Paypal as payment gateway.So I'm using Activemerchant.
Everything works fine on development machine but when I deploy my rails app to production It throws
OpenSSL::SSL::SSLError (SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed)
I'm initializing my Activemerchant as
config.after_initialize do
ActiveMerchant::Billing::Base.mode = :test
paypal_options = {
login: "bla bla",
password: "bla bla",
signature: "bla bla",
appid: "APP-80W284485P519543T"
}
::EXPRESS_GATEWAY = ActiveMerchant::Billing::PaypalExpressGateway.new(paypal_options)
end
Added HTTPS and Disabled SSLV3
After lots of googling I found that
SSLv3 was proven to be insecure with the POODLE vulnerability. You
should make sure that your system has the latest version of OpenSSL so
that you can use TLSv1.2.
So I disabled SSLV3 as shown below
openssl s_client -connect kickmarket.eu:443
CONNECTED(00000003)
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=27:certificate not trusted
verify return:1
depth=0 OU = Domain Control Validated, OU = PositiveSSL, CN = www.kickmarket.eu
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
Server certificate
-----BEGIN CERTIFICATE-----
...........................................
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL/CN=www.kickmarket.eu
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO RSA Domain Validation Secure Server CA
---
No client certificate CA names sent
Server Temp Key: ECDH, prime256v1, 256 bits
---
SSL handshake has read 2038 bytes and written 375 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-AES256-GCM-SHA384
Session-ID: 4D23F4A942AAD4264BE96EB5F1E62204269D882A64ACFBD2D139CD2F10A449A0
Session-ID-ctx:
Master-Key: 1E381DAA3BA90FE3609606716E7E9A2EB2E2F671E9F3C4005D8EBAE009103A7AB771FB2AC8B45F169F43CBD0AD352E06
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
..................................
Start Time: 1446132175
Timeout : 300 (sec)
Verify return code: 21 (unable to verify the first certificate)
---
But after restarting nginx I got the same problem.Is there Any way to fix this issue.
Any suggestion will be appreciated.
This is most likely due to the upgrade to SHA256 certification. Please review the following documentation:
https://devblog.paypal.com/paypal-ssl-certificate-changes/
The primary cause for this is the rvm installed ruby does look into the wrong directory for certificates whereas the OSX-ruby will look into the correct one.
What you wanna do is NOT TO USE any of the precompiled rubies and rather have ruby compiled on your local machine, like so:
rvm install 2.2.0 --disable-binary
You can read detailed explanation https://toadle.me/2015/04/16/fixing-failing-ssl-verification-with-rvm.html
tl;dr
Git on Windows stops connecting to github because of mysterious "SSL protocol" errors. Halp!
The Issue
I'm developing on Windows, using a private GitHub repo for source control. When I first boot my system, I'm able to access the remote repo without issue - pull, push, fetch, etc. all work just fine.
After some amount of time(*), this stops, and I get the following error:
fatal: unable to access 'https://github.com/our-team/private-repo.git/': Unknown SSL protocol error in connection to github.com:443
(*) The amount of time seems variable - I've witnessed as little as an hour or two, up to a whole day. Usually after coming back from the system sleeping, it seems to be an issue, but I don't know if it's caused by a time delay or by the system sleeping.
Checking via cURL, I get
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to github.com:443
* Closing connection 0
curl: (35) Unknown SSL protocol error in connection to github.com:443
Using set GIT_CURL_VERBOSE=1 with git pull shows similar information. Sometimes it succeeds (see below), but most of the time it fails.
Further Notes
There's a little bit of a sporadic nature to it - sometimes I can get requests to succeed, but once it starts exploding, it's generally broken 9 out of 10 requests or more.
A successful cURL request looks like:
λ curl -v "https://github.com/our-team/private-repo.git/"
* Trying 192.30.252.130...
* Connected to github.com (192.30.252.130) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: C:\Program Files (x86)\Git\bin\curl-ca-bundle.crt
CApath: none
* TLSv1.0, TLS handshake, Client hello (1):
* TLSv1.0, TLS handshake, Server hello (2):
* TLSv1.0, TLS handshake, CERT (11):
* TLSv1.0, TLS handshake, Server finished (14):
* TLSv1.0, TLS handshake, Client key exchange (16):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* TLSv1.0, TLS change cipher, Client hello (1):
* TLSv1.0, TLS handshake, Finished (20):
* SSL connection using TLSv1.0 / AES128-SHA
* Server certificate:
* subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=5157550; street=548 4th Street; postalCode=94107; C=US; ST=California; L=San Francisco; O=GitHub, Inc.; CN=github.com
* start date: 2014-04-08 00:00:00 GMT
* expire date: 2016-04-12 12:00:00 GMT
* subjectAltName: github.com matched
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
> GET /our-team/private-repo.git/ HTTP/1.1
> User-Agent: curl/7.41.0
> Host: github.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Server: GitHub.com
< Date: Mon, 11 May 2015 15:19:43 GMT
< Content-Type: text/html
< Content-Length: 178
< Location: https://github.com/our-team/private-repo/
< Vary: Accept-Encoding
< X-Served-By: 76f8aa18dab86a06db6e70a0421dc28c
<
<html>
<head><title>301 Moved Permanently</title></head>
<body bgcolor="white">
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host github.com left intact
The Question
I've googled a good bit on trying to find this (over the course of several weeks, so I don't have links), but most suggestions seem to point at certificate errors or OpenSSL version mismatches / bugs (which wouldn't be sporadic like this AFAIK).
What might be causing this failure, and how can I resolve it?
Relevant Software:
λ git --version
git version 1.9.5.msysgit.1
λ curl --version
curl 7.41.0 (i386-pc-win32) libcurl/7.41.0 OpenSSL/0.9.8zf zlib/1.2.8
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
Oddly, it turns out that the issue is that the laptop was throttled because of a weak power supply. The docking station I was using was plugged into a low-amp powersupply (3.3 A), which, while it was compatible with the laptop, immediately kicked it into a heavily-throttled mode.
Apparently, this slowed everything down enough that the SSL handshake wasn't able to complete fast enough.
We finally tracked it down after reading a Dell support forum post (http://en.community.dell.com/support-forums/laptop/f/3518/t/19363340) that discussed slowness issues. The solution there was to change the power supply.
I had also experienced this slowness, but I did not think it was related. We swapped to a high-amp power supply for the dock, and everything was fine again, and the SSL errors described above went away.
That looks like an error which could result from the security initiatives taken after the Logjam attack -- weakdh.org --.
That resulted in the suppression of some ciphers accepted in a SSL/TLS transaction.
Note that, as reported in "Cannot communicate securely with peer: no common encryption algorithm(s)", you will be able to pass the right cipher list to curl via git.
Before that, you can also try if the issue persists while using a more recent Git for Windows (like the Git 2.4.1)
Had the same issue. Disabled my wifi connection and switched to cable and everything works again. Btw: Used a Dell in Docking-Station too.