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