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.
Related
I have written separate client and server applications that use OpenSSL to exchange encrypted data. Both applications work. The only minor issue I have involves the client application. SSL_is_init_finished returns true after the client receives the first TLS handshake message. I need something that can be used to verify that the client has received the second (assumed to be last) TLS handshake message. Does the OpenSSL API provide a method?
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.
I have a problem, i made a command "openssl s_client -connect server.server:143", and the error is:
CONNECTED(00000003)
140719622096768:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown proto col:s23_clnt.c:769:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
I made that because the horde connection gives an error in login.
How can i resolve this?
openssl s_client -connect server.server:143
Port 143 is plain IMAP, that is you can not talk directly TLS to this port. If you try it you will get some data back which are not TLS, and thus strange error messages will occure. If you want to have TLS you have to either use imaps (port 993) or issue a STARTTLS command. You can also use openssl for this with
openssl s_client -connect server:143 -starttls imap
From your output it might even be that you used this option but did not put it into your question (because 7 bytes from the server would match a TLS alert, but is unusually short for an IMAP greeting). If this is the case there might be lots of reasons why the connection fails and it is not possible to pin the problem down just from your description. If you get more help look at http://noxxi.de/howto/ssl-debugging.html#hdr2.2 on how you could narrow down the problem and what you should provide on information if you need help from others.
I'm using pyOpenSSL which is a wrapper for OpenSSL. I had a client program trying to connect to my server and repeatedly was getting sslv3 alert bad certificate on the server. It wasn't until I realized it was due to the client's clock being improperly set that I was able to figure out the issue. I'm guessing that the client saw the server's certs as being dated in the "future" and somehow that resulted in a sslv3 alert bad certificate on the server.
Is there any way to get better descriptions as to why a particular cert failed? I'm assuming in this case the verification failed on the client side due to the clock not being set right, but the error on the server side is the same as if a bad certificate was sent and the verification failed on the server side.
Unfortunately the problem descriptions are fairly limited. Errors are transmitted with TLS alerts. Each alert is only a number without any additional information and there are only few alerts defined, see http://en.wikipedia.org/wiki/Transport_Layer_Security#Alert_protocol. For example there is an alert for an expired certificate, but no alert for a certificate which is not yet valid which would be necessary in your case. So all the client could send back is that the certificate is bad.
In most cases sslv3 alert bad certificate means that CA information is not provided at all or is wrong. In curl there is a parameter --cacert , for openssl s_client use -CAfile.
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.