Hi All,
Sorry, send to <openssl-users@openssl.org> missing.
Patrice.
-------- Message transféré --------
Sujet : Re: openssl s_client connection fails
Date : Wed, 18 Nov 2020 14:46:45 +0000
De : Matt Caswell <m...@openssl.org>
Pour : Patrice Guérin <guer...@talasi.fr>
On 18/11/2020 14:33, Patrice Guérin wrote:
Hello Matt,
Thank you for your very fast answer
No, I don't have access to the server though it's publicly available.
Well done ! You are a genius !
The SNI trick resolves the connection failiure...
So, I have another questions :
1/ Do I have to always add SNI support, even in the case it's not
necessary ?
It is good practice to always add SNI support. Server's that don't need
it will ignore it. Increasingly servers are requiring it. Unless you
happen to know the server's requirements before you start there is no
way of knowing before you start a connection whether the server will be
picky about it. This is one of the main reasons why the default
behaviour for s_client was changed between 1.1.0 and 1.1.1.
2/ If I want to switch to 1.1.1, are the API and libraries compatible
with 1.1.0. I've used no-deprecated, but I can remove it and rebuild
Yes 1.1.1 is backwards compatible with 1.1.0 so in theory it should be a
drop in replacement. I don't think we deprecated anything in 1.1.1 as
far as I remember so no-deprecated shouldn't make a difference. The
biggest change between 1.1.0 and 1.1.1 is the addition of TLSv1.3
support. This brings with it numerous implications for applications
using libssl which you should be aware of. See:
https://wiki.openssl.org/index.php/TLS1.3
Matt
Thank you very very much.
Kind regards,
Patrice.
Matt Caswell a écrit :
On 18/11/2020 11:24, Patrice Guérin wrote:
3072988928:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1407:SSL alert number 40
This is a very generic "something went wrong" alert that is being
received from the server and could be due to any number of issues. Do
you have access to the server in question? If so there may be more clues
in the server logs that might explain it.
Does anybody have an idea on what's going wrong ?
One thing that springs to mind that often goes wrong is SNI handling.
s_client changed between 1.1.0 and 1.1.1 to always provider SNI by
default. If the server requires SNI then it could explain this
behaviour. Your can add SNI in 1.1.0 by using the "-servername" command
line option followed by the name of the server in question, e.g.
$ openssl s_client -connect www.openssl.org -port 443 -servername
www.openssl.org
Matt
Thank you in advance.
Kind regards
Patrice.
