[PATCH] Add "pass_only" option to ssl_verify_client to enable app-only validation

Maxim Dounin mdounin at mdounin.ru
Mon Jul 23 18:31:43 UTC 2012


Hello!

On Thu, Jul 19, 2012 at 05:13:01PM -0400, mk.fg wrote:

> Hello,
> 
> Proposed patch enables use-case scenario when Nginx asks Client for TLS
> certificate but does not make any attempt to validate it, passing it to
> the application instead. Application itself if then free to decide
> whether provided certificate is valid and is able to reject it with the
> same http status codes as Nginx does.
> 
> Same use-case is also referenced in
> "http://forum.nginx.org/read.php?2,15584" and is *critical* for
> implementing protocols like WebID (http://www.w3.org/wiki/WebID), which
> relies on custom TLS certificates, which are signed with keys which are
> unknown in advance.
> With the patch, that can be accomplished by specifying
> "ssl_verify_client pass_only;" ("ssl_client_certificate" is *not* used
> in this case) and using "uwsgi_param X_CLIENT_CERT
> $ssl_client_raw_cert;" (or similar options for different backends).
> 
> Currently, Nginx supports "off", "on" and "optional" parameters to
> "ssl_verify_client" option, latter of which ("on" and "optional")
> require CA certificate (specified with "ssl_client_certificate" option)
> and perform mandatory check against it if client provides certificate.
> "optional" parameter seem to allow client to skip providing the
> certificate, but still requires CA certificate and performs the check
> (if client provides the cert), returning http status 495 if validation
> against that CA fails.
> So there is currently no way to require client certificate but perform
> it's validation in application (or on whatever backend) only, hence the
> patch.
> 
> Please consider merging the patch into nginx codebase, enabling
> aforementioned use-case in some other way, or at least commenting on why
> it might be wrong or unsuitable approach/feature (if only to block
> further proposals in the same vein).

I don't think that the patch is a right way to go.  If client 
certificates without CA being known in advance is indeed something 
required - it probably needs something like optional_no_ca instead 
as done in Apache's mod_ssl, i.e. with usual expiration checks and so on, 
but without verification against CAs.

Maxim Dounin



More information about the nginx mailing list