# Trouble with ssl\_verify\_client option **URL:** \ **Category:** NGINX\ **Created:** [November 5, 2010, 1:15am UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664 "2010-11-05T01:15:22Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![okkezSS](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/o/85f322/32.png) [@okkezSS](https://www.ruby-forum.com/u/okkezSS)\ **Post date:** [November 5, 2010, 1:15am UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/1 "2010-11-05T01:15:22Z")
Hello mailinglist, Somehow I can’t get the ssl\_verify\_client option to work properly for me. As it more and more looks like this might be a bug, I thought I’d report. I’m using 0.8.53, but upgraded from 0.7.67 because of this problem. The problem is with setting ssl\_verify\_client in any server {} block. Setting it globally (in the http{} block) works as expected, but I can’t get ssl\_verify\_client enabled for one specific server {} and not for all the others. Setting it to ‘optional’ in a server config doesn’t change much (maybe something does change, but nothing noticeable happens), though setting it to ‘on’ does deny connections without a client certificate. Sadly this, like ‘optional’, still does mean it won’t ask for a client certificate so will deny access to every request. Am I expecting the wrong things here, or is server-specific ssl\_verify\_client setting broken here? Regards, Luit van Drongelen [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Luit\_van\_Drongelen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@Luit\_van\_Drongelen](https://www.ruby-forum.com/u/Luit_van_Drongelen)\ **Post date:** [November 5, 2010, 11:29pm UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/2 "2010-11-05T23:29:59Z")
On Fri, Nov 5, 2010 at 1:14 AM, Luit van Drongelen [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Am I expecting the wrong things here, or is server-specific > ssl\_verify\_client setting broken here? My case further simplified: http { server { listen: 443; ssl on; ssl\_verify\_client optional; certificate and key stuffs; }} # DOESN’T WORK vs. http { ssl\_verify\_client: optional; certificate and key stuffs; server{listen: 443; ssl: on; }} # WORKS FINE This is the same for ssl\_verify\_client: on, where the “doesn’t work” means it’ll just stop any request. So are my expectations of ssl\_verify\_client wrong, or would this be a bug? Regards, Luit van Drongelen [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Luit\_van\_Drongelen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@Luit\_van\_Drongelen](https://www.ruby-forum.com/u/Luit_van_Drongelen)\ **Post date:** [November 6, 2010, 3:07am UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/3 "2010-11-06T03:07:43Z")
Hello! On Fri, Nov 05, 2010 at 11:28:33PM +0100, Luit van Drongelen wrote: > This is the same for ssl\_verify\_client: on, where the “doesn’t work” > means it’ll just stop any request. > So are my expectations of ssl\_verify\_client wrong, or would this be a bug? Directive ssl\_verify\_client works correctly only on per-ssl-connection basis (as well as ssl\_certificate) as it requires client certificate request during ssl handshake. This means that (unless you have SNI[1] enabled) if you have multiple ssl server{}'s listening on the same ip:port pair - you have to specify ssl\_verify\_client identical (or at least somewhat synced) for all servers on the ip:port pair in question. [1] [Server Name Indication - Wikipedia](http://en.wikipedia.org/wiki/Server_Name_Indication) Your simplified cases should both work ok (and they works ok here, and I doubt you actually tested them). Though this one will cause troubles without SNI: http { server { listen 443; server\_name [test1.example.com](http://test1.example.com); ssl on; … } server { listen 443; server\_name [test2.example.com](http://test2.example.com); ssl on; ssl\_verify\_client on; … } } Default server for port 443 is first one, [test1.example.com](http://test1.example.com), and all ssl connections will be established without certificate request (and with server certificate specified in this server - though this is probably obvious). As soon as request to [test2.example.com](http://test2.example.com) comes in - nginx will select second server, try to check client’s certificate and return 400 as there is no client certificate. Obvious solutions are: 1. Use separate ip’s for separate servers. 2. Keep ssl\_verify\_client at least “optional” in the default server for ip:port pair if you want client certificates to be available for servers on the ip:port pair in question. Note that this may cause unnecessary “select certificate to submit” dialogs in browser. 3. Use SNI. As long as you care about IE users under Windows XP - this probably isn’t an option. Maxim D. ---
**Author:** ![Luit\_van\_Drongelen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@Luit\_van\_Drongelen](https://www.ruby-forum.com/u/Luit_van_Drongelen)\ **Post date:** [November 6, 2010, 1:19pm UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/4 "2010-11-06T13:19:50Z")
On Sat, Nov 6, 2010 at 3:06 AM, Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Your simplified cases should both work ok (and they works ok here, > and I doubt you actually tested them). Though this one will cause > troubles without SNI: They do work for changing certificates, but the ssl\_verify\_client option won’t be properly used. Furthermore the server will expect a client certificate when this is set to “on”, though will not send any accepted accepted DNs (only when it’s globally set it will work). Should this mean that I have SNI disabled, how do I enable this? I use a recent version of OpenSSL, I have compiled nginx with SNI support, according to nginx -V, so what am I missing here? Regards, Luit van Drongelen [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![Luit\_van\_Drongelen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@Luit\_van\_Drongelen](https://www.ruby-forum.com/u/Luit_van_Drongelen)\ **Post date:** [November 7, 2010, 3:59am UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/5 "2010-11-07T03:59:06Z")
Hello! On Sat, Nov 06, 2010 at 01:18:11PM +0100, Luit van Drongelen wrote: > Should this mean that I have SNI disabled, how do I enable this? I use > a recent version of OpenSSL, I have compiled nginx with SNI support, > according to nginx -V, so what am I missing here? ENOPARSE. Do you mean you already using SNI to distinguish between different virtual hosts (with different certificates) on the same ip:port, and it works for certificates, but not for ssl\_verify\_client, right? This make sense: it looks like OpenSSL only changes certificate on SSL\_set\_SSL\_CTX(). Seems to be OpenSSL problem - it should apply all settings from new context, at least ones which weren’t explicitly modified for the connection in question. Attached patch implements workaround for the problem. Maxim D. ---
**Author:** ![Luit\_van\_Drongelen](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/65b543/32.png) [@Luit\_van\_Drongelen](https://www.ruby-forum.com/u/Luit_van_Drongelen)\ **Post date:** [November 7, 2010, 12:55pm UTC](https://www.ruby-forum.com/t/trouble-with-ssl-verify-client-option/198664/6 "2010-11-07T12:55:56Z")
2010/11/7 Maxim D. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid): > This make sense: it looks like OpenSSL only changes certificate on > SSL\_set\_SSL\_CTX(). Seems to be OpenSSL problem - it should apply > all settings from new context, at least ones which weren’t > explicitly modified for the connection in question. Should have made it a little more clear in the first mail that certificates switched fine but that setting didn’t in my situation. This patch seems to fix all issues I have, thanks! Regards, Luit van Drongelen [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)