I receive the following nginx log frequently and unable to get any suitable answer from google search. My nginx is having a valid SSL certificate.
Jul 15 08:21:58 web-lb01 WEB_LB01_443: 2016/07/15 08:21:58 [info]
5753#0: *7101 SSL_do_handshake() failed (SSL: error:140943F2:SSL
routines:SSL3_READ_BYTES:sslv3 alert unexpected message:SSL alert
number 10) while SSL handshaking, client: x.x.x.x, server: 0.0.0.0:443
Keep an eye on the Ciphers and protocols like TLS1.2,TLS1.1, TLS1.0 are enabled . SSL handshaking comprises of not only the SSL certificate but also a common set of ciphers and protocols are negotiated between the client and the server for further encryption.
Related
Setting up Rabbitmq with SSL
TLS server: In-state certify at ssl_handshake.erl:1368 generated SERVER ALERT: Fatal - Bad Certificate
ERROR c.t.a.derived.broker.RabbitMQBroker - Received fatal alert: bad_certificate
What can cause these error?
What is the role of the common name while generating a certificate?
Probably the client doesn't trust the CA. Make sure the client has the CA available.
I have a Gitlab installation on a Kimsufi server installed from sources.
I use Apache and HTTPS with self-signed certificate.
Almost everything is working fine.
This is the problem :
I can't clone repository via HTTPS. Only SSH works fine.
fatal: unable to access 'https://xxx/xxx/xxx.git/': The requested URL
returned error: 503
I think the problem comes from the Apache configuration (vhost).
Is there a log file somewhere or specific command I can run to debug this form client side or server side ?
Thx for help
Edit :
The request result with curl :
xxx#xxx:~/temp$ curl -v https://xxx.xxx.fr/xxx/xxx.git
* Hostname was NOT found in DNS cache
* Trying xxx.xxx.xxx.xxx...
* Connected to xx.xx.xx (xx.xx.xx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS alert, Server hello (2):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: http://curl.haxx.se/docs/sslcerts.html
curl performs SSL certificate verification by default, using a "bundle"
of Certificate Authority (CA) public keys (CA certs). If the default
bundle file isn't adequate, you can specify an alternate file
using the --cacert option.
If this HTTPS server uses a certificate signed by a CA represented in
the bundle, the certificate verification probably failed due to a
problem with the certificate (it might be expired, or the name might
not match the domain name in the URL).
If you'd like to turn off curl's verification of the certificate, use
the -k (or --insecure) option
I think I have a certificate issue... Or CA ?
The failure is intentional and is because SSLv3 is disabled. A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
I've got OptRenegotiate set as per http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions, but my server is still returning an SSL handshake failure, rather than alerting handshake failure (then sending handshake failure).
Works:
$ openssl s_client -connect my.working.server:443 -ssl3
CONNECTED(00000003)
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Fails:
$ openssl s_client -connect my.failing.server:443 -ssl3
CONNECTED(00000003)
2414208:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
Sole difference:
2414208:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
It's getting this alert to be sent that is the problem: I cannot seem to find a reference to it anywhere in the Apache documentation.
A .NET client is defaulting to using SSLv3 and it won't retry with a supported SSL version without receiving an alert before a failure.
That's not how SSL protocol negotiation works. The client announces the best version it is willing to support and the server then responds with the best version it can which is equal or lower to the clients version. If this fails some clients (mostly browsers) retry with a lower SSL version because they assume a broken server. But they use a new TCP connection for this, i.e. no kind of renegotiation inside the existing connection.
There is no such thing as a protocol upgrade, which is what you describe here.
TLS 1.0 needed to be enabled on the server for it to send an alert before a failure. The .NET client receives the alert, and tries again with a secure protocol i.e. not SSLv3.
I'm trying to run an openssl command to narrow down what the SSL issue might be when trying to send an outbound message from our system.
I found this command in another topic: Using openssl to get the certificate from a server
openssl s_client -connect ip:port -prexit
The output of this results in
CONNECTED(00000003)
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
Does this mean the server isn't presenting any certificate? I tried other systems on a different ip:port and they present a certificate successfully.
Does mutual authentication affect this command with -prexit?
--Update--
I ran the command again
openssl s_client -connect ip:port -prexit
And I get this response now
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 121 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I added -ssl3 to the command
openssl s_client -connect ip:port -prexit -ssl3
Response:
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : SSLv3
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
Start Time: 1403907236
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
Also trying -tls1
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 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
Krb5 Principal: None
Start Time: 1403907267
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
I was debugging an SSL issue today which resulted in the same write:errno=104 error. Eventually I found out that the reason for this behaviour was that the server required SNI (servername TLS extensions) to work correctly. Supplying the -servername option to openssl made it connect successfully:
openssl s_client -connect domain.tld:443 -servername domain.tld
15841:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:188:
...
SSL handshake has read 0 bytes and written 121 bytes
This is a handshake failure. The other side closes the connection without sending any data ("read 0 bytes"). It might be, that the other side does not speak SSL at all. But I've seen similar errors on broken SSL implementation, which do not understand newer SSL version. Try if you get a SSL connection by adding -ssl3 to the command line of s_client.
I encountered the write:errno=104 attempting to test connecting to an SSL-enabled RabbitMQ broker port with openssl s_client.
The issue turned out to be simply that the user RabbitMQ was running as did not have read permissions on the certificate file. There was little-to-no useful logging in RabbitMQ.
In my case the ssl certificate was not configured for all sites (only for the www version which the non-www version redirected to). I am using Laravel forge and the Nginx Boilerplate config
I had the following config for my nginx site:
/etc/nginx/sites-available/timtimer.at
server {
listen [::]:80;
listen 80;
server_name timtimer.at www.timtimer.at;
include h5bp/directive-only/ssl.conf;
# and redirect to the https host (declared below)
# avoiding http://www -> https://www -> https:// chain.
return 301 https://www.timtimer.at$request_uri;
}
server {
listen [::]:443 ssl spdy;
listen 443 ssl spdy;
# listen on the wrong host
server_name timtimer.at;
### ERROR IS HERE ###
# You eighter have to include the .crt and .key here also (like below)
# or include it in the below included ssl.conf like suggested by H5BP
include h5bp/directive-only/ssl.conf;
# and redirect to the www host (declared below)
return 301 https://www.timtimer.at$request_uri;
}
server {
listen [::]:443 ssl spdy;
listen 443 ssl spdy;
server_name www.timtimer.at;
include h5bp/directive-only/ssl.conf;
# Path for static files
root /home/forge/default/public;
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;
# ...
# Include the basic h5bp config set
include h5bp/basic.conf;
}
So after moving (cutting & pasting) the following part to the /etc/nginx/h5bp/directive-only/ssl.conf file everything worked as expected:
# FORGE SSL (DO NOT REMOVE!)
ssl_certificate /etc/nginx/ssl/default/2658/server.crt;
ssl_certificate_key /etc/nginx/ssl/default/2658/server.key;
So it is not enough to have the keys specified only for the www version even, if you only call the www version directly!
I was getting the below as well trying to get out to github.com as our proxy re-writes the HTTPS connection with their self-signed cert:
no peer certificate available
No client certificate CA names sent
In my output there was also:
Protocol : TLSv1.3
I added -tls1_2 and it worked fine and now I can see which CA it is using on the outgoing request. e.g.:
openssl s_client -connect github.com:443 -tls1_2
I had a similar issue. The root cause was that the sending IP was not in the range of white-listed IPs on the receiving server. So, all requests for communication were killed by the receiving site.
I have met the same problem . but use IP fine;
I specify ip host in /etc/hosts
use IP work fine, but host can't
I'm using Java 8, Netty 5 Alpha.
I added the certificates from Comodo to the keystore, and according to a test website suggested by my certificate provider they are installed correctly.
But if I try to connect using Firefox, Chrome, or curl, I get errors.
From curl -v I see that it gets the correct header, but then SSLv3, TLS alert, Server hello (2):. This seems to correspond with debug messages from Java:
SEND TLSv1.2 ALERT: warning, description = close_notify
WRITE: TLSv1.2 Alert, length = 32
fatal error: 80: Inbound closed before receiving peer's close_notify: possible truncation attack?
Firefox: SSL received a record that exceeded the maximum permissible length.
From openssl s_client -connect ...:
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-DES-CBC3-SHA
verify error:num=19:self signed certificate in certificate chain
SSL handshake has read 5982 bytes and written 531 bytes
I've read elsewhere about NullPointerExceptions somewhere causing internal Java security stuff to fail. But there's no clear solutions.