[PATCH] SSL: support for client proxy certificates

Francesco Giacomini francesco.giacomini at cnaf.infn.it
Mon Mar 18 17:34:27 UTC 2019


On Mon, Mar 18, 2019 at 07:29:38PM +0300, Maxim Dounin wrote:
> > > Since nginx does not call X509_verify_cert() directly, the only 
> > > documented approach is to use the OPENSSL_ALLOW_PROXY_CERTS 
> > > environment variable.
> > 
> > I think they simply forgot to change the documentation.
> Well, this is likely what indeed happened.  But either way there 
> is a bug in OpenSSL: either the code or the documentation is 
> wrong.  And, given the number of recent cases with OpenSSL 
> changes, I really want them to decide it themselves where the bug 
> is.

Agreed. I'll comment in the issue you mentioned asking for

I also think that when they say "if the application directly calls
X509_verify_cert()", they don't mean "directly" literally; I think
they rather mean "if the application has control over the SSL context
used to verify the cert".

> Note well that the documentation never mentions that the 
> environment variable is a hack and properly written programs which 
> simply use client certificate authentication as with 
> SSL_CTX_set_verify(SSL_VERIFY_PEER) should use 
> X509_STORE_CTX_set_flags(X509_V_FLAG_ALLOW_PROXY_CERTS) instead.  
> Instead, it specifically mentions that OPENSSL_ALLOW_PROXY_CERTS 
> should be used in this case, providing no other alternatives.  
> This makes removing the OPENSSL_ALLOW_PROXY_CERTS environment 
> variable support highly questionable from compatibility point of 
> view, since no application could foresee it will be removed.

The definition of "hack" was in the code and in the commit that
removed it


> > As far as I know, proxy certificates were introduced as the basic
> > mechanism for authN and authZ in Grid computing, where they are still
> > widely used. It may well be that's the only field though. Indeed also
> > the submitter of that issue is in that field.
> Thanks for the details.  Indeed it looks like these are only used 
> in Grid computing.  It would be interesting to hear how nginx is 
> used in such workloads.

Very little. The module I mentioned enables nginx to read the contents
of these proxy certificates -- they contain an extension in the form
of an attribute certificate with authZ information -- because we want
to use it as a reverse proxy. We'll see how it goes.

> This approach may have problems with further nginx changes, but 
> likely it will work good enough.

Good, thanks.

> For maximum compatibility, my recommendation would be to ask 
> OpenSSL to introduce an openssl.cnf option, so you will be able to 
> configure things via openssl.cnf.

I'll check that option as well.

Thanks again.


More information about the nginx-devel mailing list