[PATCH] (re-post) Add "optional_no_ca" option to ssl_verify_client to enable app-only CA chain validation

Mike Kazantsev mk.fraggod at gmail.com
Thu Sep 27 14:05:25 UTC 2012


On Tue, 25 Sep 2012 08:39:28 +0400
Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Sat, Sep 22, 2012 at 05:09:53PM +0600, Mike Kazantsev wrote:
> 
> [...]
> 
> > > In particular, I would like someone to actually test if the 
> > > error_page 495 aproach works instead as suggested here:
> > > 
> > > http://mailman.nginx.org/pipermail/nginx-devel/2012-August/002650.html
> > > 
> > 
> > It doesn't seem to be of much use in current state, problems:
> > 
> >  - Requires "ssl_client_certificate" to be set to some valid
> >    certificate, which then shouldn't actually never be used in this
> >    case.
> 
> This actually counts as a separate problem.  I think it should be 
> possible to specify empty certificate authorities list to be sent 
> to clients even if nginx does actual verification.  Part of the 
> problem is addressed by the ssl_trusted_certificate directive which is 
> going to be introduced along with OCSP stapling patches.
> 

Ok.

Don't think finding any cert to put there should be a problem anyway.


> >  - In case of "ssl_verify_client" set to "on" or "optional", setting
> >    "error_page 400 495 496 =200 /altpath;" doesn't seem to stop nginx
> >    from returning "HTTP/1.1 400 Bad Request" response with "400 The SSL
> >    certificate error" in html body.
> > 
> >    This code in ngx_http_request.c is probable cause of that:
> > 

...

> > 
> >    I'm still unsure if it's a general bug in ssl module or some error
> >    in my configuration above, because docs clearly state that error
> >    should be handled by error_page and it doesn't seem to be.
> 
> Works fine here:
> 
>     ssl_verify_client on;
>     ssl_client_certificate ca.crt;
>  
>     error_page 495 = /foo;
> 
>     location = /foo {
>         return 200 "dn: $ssl_client_s_dn, verify: $ssl_client_verify\n";
>     }
> 
> $ openssl s_client -connect ... -cert ... -key ...
> ...
> GET / HTTP/1.0
> 
> HTTP/1.1 200 OK
> Server: nginx/1.3.6
> Date: Tue, 25 Sep 2012 02:37:45 GMT
> Content-Type: text/plain
> Content-Length: 35
> Connection: close
> 
> dn: /CN=mdounin.ru, verify: FAILED
> 

With a bit more universal catch-all config like this:

  error_page 495 = @cert_err;
  location @cert_err { ...

It seem to work pretty much as desired, was some misconfiguration on my
part before, I guess.

Since it's possible to use and rewrite $uri in named locations, I don't
see any obvious flaws in this approach, so I think "error_page" might
make this patch redundant indeed.

I'll try it out (and ping other users) and re-raise the issue with
modified patch if there'll be any less obvious issues with it.

Eric, does it work for your use-case as well?


> >  - "ssl_verify_client off;" isn't much useful, because it doesn't return
> >    clent certificate and doesn't check it in any way.
> > 
> >  - "ssl_verify_client on;", still gives all-or-nothing check, though
> >    I see that it's what might indeed be desirable, as Eric indicated.
> > 
> >  - I think it's really non-obvious way to do it.
> > 
> > 

...

> See below for some comments.

I'll look into addressing these, thanks, though as noted, the patch
itself doesn't seem to be necessary, since "error_page 495 ..." works.


-- 
Mike Kazantsev // fraggod.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20120927/bf511588/attachment.bin>


More information about the nginx-devel mailing list