I've come across several hosts that throw SSL3 handshake errors even though I explicitly request TLS 1.2. Why is this? Am I using the openssl client wrong?

$ openssl s_client -tls1_2 -connect i-d-images.vice.com:443
140735150146384:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1472:SSL alert number 40
140735150146384:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:656:
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
No ALPN negotiated
    Protocol  : TLSv1.2
    Cipher    : 0000
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1444078671
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)

2 Answers 2


In SSL/TLS, the client does not request a specific protocol version; the client announces the maximum protocol version that it supports, and then the server chooses the protocol version that will be used. Your client does not tell "let's use TLS 1.2"; it says "I know up to TLS 1.2".

A client may have its own extra requirements, but there is no room to state them in the ClientHello message. If the client wants to do TLS 1.2 only, then he must announce "up to TLS 1.2" in its ClientHello, and also close the connection if the server responds with a message that says anything else than "let's do TLS 1.2". In your case, things did not even reach that point: the server responded with a fatal alert 40 ("handshake_failure", see the standard). As @dave_thompson_085 points out, this is due to a lack of SNI: this is an extension by which the client documents in its ClientHello message the name of the target server. SNI is needed by some servers because they host several SSL-enabled sites on the same IP address, and need that parameter to know which certificate they should use. The command-line tool openssl s_client can send an SNI with an explicit -servername option.

As @Steffen explained, SSL 3.0 and all TLS versions are quite similar and use the same record format (at least in the early stage of the handshake) so OpenSSL tends to reuse the same functions. Note that since the server does not respond with a ServerHello at all, the protocol version is not yet chosen, and SSL 3.0 is still, at least conceptually, a possibility at that early point of the handshake.


ssl3_read_bytes and ssl3_writes_bytes deal with SSL3-style frames. These are the same with later versions, i.e. TLS1.x. Thus the same functions get used, even though their names might suggest a different thing. There is no specific tls1_read_bytes function or similar.

  • 4
    This server, like many today, apparently requires SNI (Server Name Indication), which is not the default for openssl s_client. Add -servername i-d-images.vice.com. Oct 6, 2015 at 4:16
  • @dave_thompson_085 Is there a way to know that the server requires SNI?
    – richid
    Oct 6, 2015 at 18:18
  • 1
    @richid: see the SSLLabs report: "This site works only in browsers with SNI support." Oct 6, 2015 at 18:41
  • 1
    @richid: and also, adding the -servername option actually allows connection to proceed (try it !). Oct 7, 2015 at 16:32

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .