Repository navigation
ssl.create_default_context() throws: "ssl.SSLError: [X509] unknown error (_ssl.c:4035)" #108721
Description
Bug report
Checklist
- I am confident this is a bug in CPython, not a bug in a third-party project
- I have searched the CPython issue tracker,
and am confident this bug has not been reported before
CPython versions tested on:
3.11
Operating systems tested on:
Windows
Output from running 'python -VV' on the command line:
Python 3.11.5 (tags/v3.11.5:cce6ba9, Aug 24 2023, 14:38:34) [MSC v.1936 64 bit (AMD64)]
A clear and concise description of the bug:
In one of my systems, this triggers an exception in Python 3.11.5 and works fine in Python 3.11.4:
import ssl
ssl.create_default_context()The exception is:
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Program Files\Python311\Lib\ssl.py", line 775, in create_default_context
context.load_default_certs(purpose)
File "C:\Program Files\Python311\Lib\ssl.py", line 596, in load_default_certs
self._load_windows_store_certs(storename, purpose)
File "C:\Program Files\Python311\Lib\ssl.py", line 588, in _load_windows_store_certs
self.load_verify_locations(cadata=certs)
ssl.SSLError: [X509] unknown error (_ssl.c:4035)
The cause is a couple of TFS certificates in the Windows "CA" store:
If I remove one of these certificates (doesn't matter which one, I have tested both by removing, reimporting, etc.), the issue goes away.
It looks like commit 77e0919 is causing the issue. I have created a custom build of main with lines 670-673 of Modules/_ssl.c commented:
// if (ERR_GET_LIB(e) == ERR_LIB_SSL &&
// ERR_GET_REASON(e) == SSL_R_CERTIFICATE_VERIFY_FAILED) {
// type = state->PySSLCertVerificationErrorObject;
// }When using this custom build (and the two certificates in the store), the issue does not occur.
Attached you'll find a zip with the two certificates (in case anyone is wondering, they are from a sandbox which is no longer in use) and a more elaborate example which finds out which certificates cause an issue by testing them one at a time (originally I had three certificates).
Activity
AlexWaygood commentedon Aug 31, 2023
Cc. @pablogsal @Yhg1s
terryjreedy commentedon Aug 31, 2023
The fact that 3.11.5 now raises an exception is not necessarily a bug. 77e0919 fixed a bug of not raising when appropriate. The claim is that the fix also raises when it should not.
bh1428 commentedon Aug 31, 2023
Indeed, thank you for the addition. As far as I can see there is nothing wrong with the certificates and if only one is present everything works as expected. Something seems to be handled differently by OpenSSL when two (or more) of these certificates are present (which may have been always the case) and that is now caught.
pablogsal commentedon Aug 31, 2023
Something has to be wrong with these certificates because the new code path is only triggered when there is an error and the error is that the cert could not be verified:
Unfortunately I am awaiting surgery in my hand this week and I cannot take a look at this. @ambv could you take a look if you have sone time?
In particular is unclear to me how this code is causing the problem when the code only triggers when OpenSSL tells us that there is an error and that the reason is a failure to verify a certificate.
bh1428 commentedon Aug 31, 2023
Initially I thought there must be something wrong with the certificates as well. I have to admit I don't know everything about X509 certificates but I cannot find an error.
The only thing I noticed is: they are created within a couple of minutes of each other and the error only occurs when BOTH certificates are present. Individually, when only one is present (doesn't matter which one) everything is working fine.
bh1428 commentedon Sep 1, 2023
The last comment from @pablogsal made me think and re-test things. Please ignore my comment about commit 77e0919, the issue is NOT caused by that commit. I'm sorry, my apologies, I didn't doublecheck everything properly.
These are working as expected (do not have this issue):
main(I used this one for my initial test build)3.12.0rc1So the latest (pre-release) versions do not have this issue at the moment.
Commit 6193f78 is still okay:
The next commit 263d8aa after commit 6193f78 is the first with the issue:
So... I was wrong, in hindsight commit 263d8aa seems to introduce this issue.
bh1428 commentedon Sep 14, 2023
Did some further investigation and when I apply the changes from gh-100372 (manually) to
Modules/_ssl.c(in3.11.5) and recompile the issue goes away.So... the fix for this issue seems to be gh-100372 which is in
mainand3.12.0rc2but not in3.11.5.@pablogsal: my apologies if this is a stupid question, but... what is the proper procedure to get gh-100372 into 3.11 as well?
pablogsal commentedon Sep 15, 2023
You should request a backport in the PR (I don't have the context for that PR but I think @Yhg1s would know if it makes sense to backport)
serhiy-storchaka commentedon Aug 9, 2025
Can this still be reproduced, after fixing #79846?
bh1428 commentedon Aug 10, 2025
Maybe I don't understand your question (or you comment was for another thread), but this is a Python 3.11 issue. In 3.12 this is fixed in gh-100372 (as part of 3.12.0rc2). As far as I can see #79846 is for Python >= 3.12 (i.e. fixes nothing in 3.11).
The latest Python 3.11 still has this issue (I can reproduce with commit 3511c2e) and that will not change. Although there is a fix for 3.11 (#100373 would fix 3.11 as well); it is "...not serious enough to backport to security-only releases...". I can completely understand that.
Python 3.12 does not have this issue with similar / comparable (TFS) certificates.
serhiy-storchaka commentedon Aug 10, 2025
#79846 fixed some SSLError's, so I wondered if this fixed also this issue. But if this issue is 3.11-only, it should be closed. Thanks for the confirmation.