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:
> Thank you very very much.
> Kind regards,
> 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
>>> Thank you in advance.
>>> Kind regards