[PATCH] SSL: support for client proxy certificates
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
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
> > 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.
> 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.
More information about the nginx-devel