Opened 10 years ago

Closed 10 years ago

#472 closed defect (invalid)

ssl_client_verify fails in Safari

Reported by: Catchall Account Owned by:
Priority: major Milestone:
Component: nginx-module Version: 1.3.x
Keywords: ssl, ssl_client_verify Cc:
uname -a: Linux myserver 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
nginx -V: nginx version: nginx/1.4.1 (Ubuntu)
TLS SNI support enabled
configure arguments: --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-ipv6 --with-mail --with-mail_ssl_module --add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-auth-pam --add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-dav-ext-module --add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-echo --add-module=/build/buildd/nginx-1.4.1/debian/modules/nginx-upstream-fair --add-module=/build/buildd/nginx-1.4.1/debian/modules/ngx_http_substitutions_filter_module

Description

nginx version: nginx/1.4.1 (Ubuntu),
client: Safari 7.0.1 (9537.73.11) on Mac OSX 10.9.1 build 13B42

When ssl_client_verify is set to "optional", access via Safari prompts to use a client cert in the keychain that appears to have been autogenerated. The client cert, of course, is not valid for this SSL transaction (don't know where it chains, or even what it's used for). The three options are "Always allow", "Deny", and "Allow". None of the options result in proper behavior.

When either of the "Allow" variants is selected, nginx responds with

10.0.1.4 - - [20/Dec/2013:11:43:38 -0800] "GET / HTTP/1.1" 400 239 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_1) AppleWebKit/537.73.11 (KHTML, like Gecko) Version/7.0.1 Safari/537.73.11" "FAILED" "/CN=com.apple.idms.appleid.prd.734c<elided>3513d3d" and a 400 "400 Bad Request / The SSL certificate error [sic]" is returned to the client.

When the "Deny" option is selected (three times), the request doesn't appear to be sent by Safari. It returns "Safari can't open the page https://10.0.1.14 because Safari can't establish a secure connection to the server".

This could be a bug in the way Safari handles client cert requests, but it's impacting client access to nginx, especially since ssl_client_verify is an all-or-nothing proposition right now (you can't enable it per location).

Firefox has no issue.

Change History (2)

comment:1 by Catchall Account, 10 years ago

Deleting the certificate and key in OSX solves this issue, but it is unknown at this time what other effect removal of the cert/key will have on system operations.

comment:2 by Maxim Dounin, 10 years ago

Resolution: invalid
Status: newclosed

For me it looks like you are right and it's Safari problem. If you want to workaround this on nginx side, you may try using ssl_verify_client optional_no_ca with additional checks on the $ssl_client_verify variable.

Note: See TracTickets for help on using tickets.