-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSLContext doesn't support loading a CRL #53059
Comments
SSL Context should support loading a CRL. See M2Crypto patches: Or PyOpenSSL branch supporting CRL: |
Is it enough to just load a CRL file, or is other functionality usually needed? The following APIs should help us do it:
And also for configuration (enable CRL checking on the context):
|
Yes, you are right. OpenSSL uses the same API to load certs and CRLs. CRL checks must be enabled, though. |
The patch implements SSLContext.verify_flags in order to enable CRL checks. It comes with documentation, a unit test and a new CRL file. |
My patch is inspired by mod_ssl: http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/ssl/ssl_engine_init.c?view=markup#l697 CRLs can already be loaded with SSLContext.load_verify_locations(). The patch exposes the verification flags of SSLContext's X509_STORE. With X509_V_FLAG_CRL_CHECK OpenSSL requires (!) a CRL that matches the issuer of leaf certificate of the chain (the peer's cert). X509_V_FLAG_CRL_CHECK | X509_V_FLAG_CRL_CHECK_ALL also requires CRLs for all intermediate certs of the peer's cert chain. |
The new patch addresses your review. I have altered the new to FLAGS_NONE, FLAGS_CLR_CHECK_LEAF etc. |
That sounds too generic. How about VERIFY_CRL_NONE, etc. |
It *is* generic. The flags are not about CRL alone, http://www.openssl.org/docs/crypto/X509_VERIFY_PARAM_set_flags.html#VERIFICATION_FLAGS |
That's why I proposed VERIFY_xxx, e.g. VERIFY_CRL_NONE. Calling some flags "FLAGS" is senseless, it's like calling an integer |
s/FLAGS_/VERIFY_/g ? OK, I don't have hard feelings. :) |
And VERIFY_NONE should be VERIFY_CRL_NONE IMO. |
But it's not about CRL alone. How about VERIFY_DEFAULT = 0 ? |
Sounds good. |
New changeset 83805c9d1f05 by Christian Heimes in branch 'default': |
memo to me: add whatsnew entry |
This change seems to have broken the OS X 10.4 Tiger buildbot: _ssl.c:2240: error: 'struct x509_store_st' has no member named 'param' http://buildbot.python.org/all/builders/x86%20Tiger%203.x/builds/7370 |
:( I seriously need access to a Darwin or OSX box. This is the second time I broke the build on OSX. Ned Deily <report@bugs.python.org> schrieb:
|
10.4 is *very* old: $ /usr/bin/openssl version
OpenSSL 0.9.7l 28 Sep 2006 If you kept around that version of the headers and libs, you'd probably catch most of the problems. |
This problem also breaks the 32-bit OS X installer build. |
New changeset 40d4be2b7258 by Christian Heimes in branch 'default': |
The _ssl module compiles again with OpenSSL 0.9.7. |
New changeset 1508c4c9e747 by R David Murray in branch 'default': |
What is the status of this issue? Is it fixed or not? The What's New in Python 3.4 document says that Python 3.4 can load CRL. |
Yes, Python 3.4 can load and use CRLs. |
Great work Christian, I was expecting this feature since many years :-) |
It was *really* trivial. I just had to expose two simple OpenSSL APIs to enable / disable CRL. All versions of Python could already load the CRLs but CRL checks could not be enabled. |
It was trivial thanks to all the work done before around SSLContext. For example, Python 2.7 doesn't have SSLContext, so adding support for CRL in Python 2.7 is non-trivial :-/ |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: