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?

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:
name of the store (e.g. "CA", "MY", "ROOT"), see http://msdn.microsoft.com/en-us/library/windows/desktop/aa376560%28v=vs.85%29.aspx
cert_type:
"certificate" or "crl"
data:
certificate bytes (as far as I know the certs are stored in DER format)
encoding_type:
integer encoding X509_ASN_ENCODING or PKCS_7_ASN_ENCODING

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':
Issue bpo-17134: Add ssl.enum_cert_store() as interface to Windows' cert store.
http://hg.python.org/cpython/rev/10d325f674f5

New changeset 10d325f674f5 by Christian Heimes in branch 'default':
Issue bpo-17134: Add ssl.enum_cert_store() as interface to Windows' cert store.
http://hg.python.org/cpython/rev/10d325f674f5

I don't want to sound annoying, but I would have liked to review this
before it goes in. Could it wait a few days? (I'm sure it can :-))

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
http://msdn.microsoft.com/en-us/library/aa381493%28v=vs.85%29.aspx
http://www.alvestrand.no/objectid/1.3.6.1.5.5.7.3.html

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:

• Different functions for certs and CRLs: enum_certificates() / enum_crls()

• encoding is now a string ('x509_asn' or 'pkcs_7_asn')

• for certificates trust information is either a set of OIDs or True. The OIDs can be interpreter with the new functions bpo-19448.

Both functions are intended to be low level interfaces to Window's cert store.

The feature is not yet production-ready but part of the feature is already in 3.4. It depends on bpo-19448 and bpo-16487, too. What shall I do about it?

New changeset 9adcb61ea741 by Christian Heimes in branch 'default':
Issue bpo-17134: Finalize interface to Windows' certificate store. Cert and
http://hg.python.org/cpython/rev/9adcb61ea741

The test is failing:

http://buildbot.python.org/all/builders/x86%20Windows%20Server%202003%20%5BSB%5D%203.x/builds/1758/steps/test/logs/stdio

======================================================================
FAIL: test_enum_certificates (test.test_ssl.BasicSocketTests)
----------------------------------------------------------------------

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':
Issue bpo-17134: check certs of CA and ROOT system store
http://hg.python.org/cpython/rev/de65df13ed50

The tests are passing again. Thanks!