Problem with ECC certificates

Hi,

I’m having some strange issues using nginx 1.6 with ECC certs.
Handshakes fail for clients using TLSv1.2 and SNI but only if the
requested server block is not the default_server. The config looks like
this:

http {
ssl_certificate ecc.crt;
ssl_certificate_key ecc.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH+kEECDH+AESGCM:HIGH+kEECDH:HIGH+kEDH:HIGH:!aNULL;
ssl_prefer_server_ciphers on;
ssl_dhparam dhparam4096.pem;

server {
listen [::]:443 ssl spdy default_server ipv6only=off;
server_name a.example.com;
root /var/www/a;
}

server {
listen [::]:443 ssl spdy;
server_name b.example.com;
root /var/www/b;
}
}

This configuration works for:

  • TLSv1.0/TLSv1.1 with SNI
  • TLSv1.2 without SNI
  • TLSv1.2 with SNI, but only for a.example.com

It does not for TLSv1.2 with SNI for b.example.com:

openssl s_client -connect b.example.com:443 -servername b.example.com


139718860113552:error:14094438:SSL routines:SSL3_READ_BYTES:tlsv1 alert
internal error:s3_pkt.c:1256:SSL alert number 80
139718860113552:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:177:

The error.log says:
[crit] 21172#0: *486 SSL_do_handshake() failed (SSL: error:1409B044:SSL
routines:SSL3_SEND_SERVER_KEY_EXCHANGE:internal error) while SSL
handshaking, client: ::ffff:XXX.XXX.XXX.XXX, server: [::]:443

Same result when using Firefox/NSS.

Everything works fine, if only the default_server uses the ECC cert:

http
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH+kEECDH+AESGCM:HIGH+kEECDH:HIGH+kEDH:HIGH:!aNULL;
ssl_prefer_server_ciphers on;
ssl_dhparam dhparam4096.pem;

server {
listen [::]:443 ssl spdy default_server ipv6only=off;
server_name a.example.com;
root /var/www/a;
ssl_certificate ecc.crt;
ssl_certificate_key ecc.key;
}

server {
listen [::]:443 ssl spdy;
server_name b.example.com;
root /var/www/b;
ssl_certificate rsa.crt;
ssl_certificate_key rsa.key;
}
}

Am I doing something wrong or is this a bug?

Regards,
Markus

nginx version: nginx/1.6.0
TLS SNI support enabled
configure arguments: --with-cc-opt=‘-g -O2 -fstack-protector
–param=ssp-buffer-size=4 -Wformat -Wformat-security
-Werror=format-security -D_FORTIFY_SOURCE=2’
–with-ld-opt=‘-Wl,-Bsymbolic-functions -Wl,-z,relro’
–prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf
–http-log-path=/var/log/nginx/access.log
–error-log-path=/var/log/nginx/error.log
–lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid
–http-client-body-temp-path=/var/lib/nginx/body
–http-fastcgi-temp-path=/var/lib/nginx/fastcgi
–http-proxy-temp-path=/var/lib/nginx/proxy
–http-scgi-temp-path=/var/lib/nginx/scgi
–http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit
–with-ipv6 --with-http_ssl_module --with-http_stub_status_module
–with-http_realip_module --with-http_auth_request_module
–with-http_addition_module --with-http_dav_module
–with-http_geoip_module --with-http_gzip_static_module
–with-http_image_filter_module --with-http_spdy_module
–with-http_sub_module --with-http_xslt_module --with-mail
–with-mail_ssl_module
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-auth-pam
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-dav-ext-module
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-echo
–add-module=/build/buildd/nginx-1.6.0/debian/modules/nginx-upstream-fair
–add-module=/build/buildd/nginx-1.6.0/debian/modules/ngx_http_substitutions_filter_module

On 04.05.2014 16:52, Markus Weippert wrote:

I’m having some strange issues using nginx 1.6 with ECC certs.
Handshakes fail for clients using TLSv1.2 and SNI but only if the
requested server block is not the default_server.

Had a further look into that. The problem seems to occur if nginx is
built against openssl shipped with Ubuntu 12.04. The official repository
version of nginx is also affected.
Compiling nginx with the latest upstream release works as expected.
Also, no problems on Ubuntu 13.10.

Hello!

On Wed, May 07, 2014 at 08:30:37PM +0200, Markus Weippert wrote:

Also, no problems on Ubuntu 13.10.
The “SSL3_SEND_SERVER_KEY_EXCHANGE:internal error” message comes
from OpenSSL, so it looks like the problem is OpenSSL version
used.


Maxim D.
http://nginx.org/