Setting ssl_ecdh_curve to secp384r1 does not work
Florian Reinhart
florian at bottledsoftware.de
Tue Jul 5 15:02:07 UTC 2016
Thanks a lot for your suggestions.
It is the same certificate on both servers and it is indeed a secp256r1 aka prime256v1 certificate. So does this mean, I have to use prime256v1 for ssl_ecdh_curve with this certificate? It’s still strange that it used to work before...
Here is what the error log says:
2016/07/05 16:57:09 [info] 2525#2525: *115 SSL_do_handshake() failed (SSL: error:1408A0C1:SSL routines:ssl3_get_client_hello:no shared cipher) while SSL handshaking, client: 192.168.241.1, server: 0.0.0.0:443
Thanks again!
> On 05 Jul 2016, at 16:39, Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> Hello!
>
> On Tue, Jul 05, 2016 at 04:02:21PM +0200, Florian Reinhart wrote:
>
>> Hi Maxim!
>>
>> That’s what I thought. However, all clients can access the nginx server on the old Ubuntu 14.04 server, which uses the same config,
>>
>> I tested the following clients on OS X 10.11.5, all failed to connect:
>>
>> curl, installed from Homebrew: curl 7.49.1 (x86_64-apple-darwin15.5.0) libcurl/7.49.1 OpenSSL/1.0.2h zlib/1.2.5 nghttp2/1.12.0
>> Safari 9.1.1 (11601.6.17)
>> Chrome 51.0.2704.106
>> Firefox 47.0.1
>>
>> That’s why I don’t think it is a client issue.
>
> Yes, at least browsers are expected to support secp384r1, so it's
> probably something different.
>
> Which certificate do you use? Is it the same as on the old
> server? Such a situation can easily happen if the only
> certificate available is ECDSA one and uses, e.g., prime256v1 (not
> secp384r1), but only secp384r1 is enabled by the configuration.
>
> Looking into nginx error logs might also somewhat help to diagnose
> what goes on here.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
More information about the nginx
mailing list