-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
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
Use Windows' certificate store for CA certs #61336
Comments
I found a recipe how to access the Windows certificate store and dump its content as PEM. The code doesn't look complicated and could be added to _ssl.c http://fixunix.com/openssl/254866-re-can-openssl-use-windows-certificate-store.html |
Isn’t this part of bpo-13655? One feature is usually discussed for all platforms in one bug report. (Sorry for all the bureaucracy in your recent reports, but it helps keep things manageable :) |
I like to split up tasks in small subtasks. It's true that bpo-13655 benefits from this feature but it can be implemented without this ticket. This enhancement also requires some addition to API and bindings to Windows' crypt32.dll. It might be inappropriate to add it to bpo-13655 because we need to backport bpo-13655 to Python 2.6 to 3.3. |
Sounds promising. Do you think this should be hooked into SSLContext.set_default_verify_paths, or be exposed as a separate method? |
If there were an API which exposed the certificate material, then this would be more useful to libraries trying to do other things (present debugging information, use an alternate SSL implementation *wink*, etc). If this is *only* wrapped up inside set_default_verify_paths then many of these extra things are impossible with a seconding binding to the same API. |
Yes, I'm planing to expose the low level API. I prefer to do as much work in Python space as possible. The information is just too useful to 3rd parties, too. I'm thinking about one low level function that interfaces Windows's cert store. The rest can be build on top of this function and bpo-18138. enum_system_store(store_name, cert_type="certificate") -> [(cert_data, encoding_type), ...] store_name: |
First patch. I have not yet verified that the return data can be loaded by openssl. Also I need to verify the error paths and add some tests, too. |
I fixed a ref leak and added some tests. |
New patch with fixed doc string and indention. http://msdn.microsoft.com/en-us/library/windows/desktop/aa377189%28v=vs.85%29.aspx explains how encoding type shall be interpreted. I haven't seen PKCS#7 certs on my Windows system, though. Instead of a flag I could also return a string: "CERTIFICATE" for X509_ASN_ENCODING cert, "X509 CRL" for X509_ASN_ENCODING CRL or "PKCS7" for PKCS#7 encoded certs. |
New changeset 10d325f674f5 by Christian Heimes in branch 'default': |
I don't want to sound annoying, but I would have liked to review this |
Ezio already reviewed my code. But sure I can wait a couple of days. The second part of the patch depends on bpo-18138 anyway. |
I guess I have to revise my patch and go throw Windows' crypto lookup functions... Automatic CA root certificate updates on Windows http://netsekure.org/2011/04/automatic-ca-root-certificate-updates-on-windows/ |
The current implementation doesn't check the trust settings and purpose of certs. CertGetCertificateContextProperty() with CERT_ENHKEY_USAGE_PROP_ID returns a ASN.1 structure. I just have to figure out how to parse the CTL_USAGE struct ... http://msdn.microsoft.com/en-us/library/aa376079%28v=vs.85%29.aspx |
The new patch splits up the one function into enum_certificates() and enum_crls(). enum_certificates() now returns also trust settings for the certificate. Internally it maps the most common OIDs to human readable names. The patch comes without doc updates yet. |
Here is a simplified version of my patch with doc updates. Changes:
Both functions are intended to be low level interfaces to Window's cert store. |
New changeset 9adcb61ea741 by Christian Heimes in branch 'default': |
The test is failing: ====================================================================== Traceback (most recent call last):
File "E:\Data\buildslave\cpython\3.x.snakebite-win2k3r2sp2-x86\build\lib\test\test_ssl.py", line 553, in test_enum_certificates
self.assertIn(serverAuth, names)
AssertionError: '1.3.6.1.5.5.7.3.1' not found in {'1.3.6.1.5.5.7.3.3', '1.3.6.1.4.1.311.10.3.5', '2.16.840.1.113730.4.1', '2.16.840.1.113733.1.8.1'} |
That's strange. It looks like the Win2k box has no root CA certs for serverAuth installed whatsoever. I'm adding Matthias to this ticket. |
New changeset de65df13ed50 by Christian Heimes in branch 'default': |
The tests are passing again. Thanks! |
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: