Opened 11 years ago
Closed 11 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 , 11 years ago
comment:2 by , 11 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
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.