Hello. 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 clarification. 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 https://github.com/openssl/openssl/commit/8e21938ce3a5306df753eb40a20fe30d17cf4a68 > > 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. F. _______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
