You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
SSLError(58, '[ASN1] nested asn1 error (_ssl.c:4174)') and SSLError(0, 'not enough data: cadata does not contain a certificate (_ssl.c:4159)') #104135
This code is causing many Python programs to fail when downloading dependencies.
It is loading all root certs from the Windows certificate store at once, and it fails if it encounters a single malformed certificate instead of ignoring it and not adding it to its own trust store.
def _load_windows_store_certs(self, storename, purpose):
certs = bytearray()
try:
for cert, encoding, trust in enum_certificates(storename):
try:
self.load_verify_locations(cadata=cert)
except SSLError:
warnings.warn("Bad certificate in Windows certificate store")
else:
# CA certs are never PKCS#7 encoded
if encoding == "x509_asn":
if trust is True or purpose.oid in trust:
certs.extend(cert)
except PermissionError:
warnings.warn("unable to enumerate Windows certificate store")
return certs
It is very likely this is not enough to fix it properly so if anyone has a better idea on how to solve this issue please advise.
Before you do, I'd like you to have in mind the following things:
The current error message (stacktrace) shown by Python doesn't help the end user understand the error, much less find the offending certificate
Even if it did, regular users trying to run a Python application may not have local admin rights to remove those certificates from the OS root CA store
Even if they had local admin rights, randomly removing root CA certificates trying to figure out which one is responsible can render their operating system unusable
Even if they had the required knowledge of which CAs they can safely remove, they might need those offending certificates anyway and removing them would just break some other application or intranet website they are using
In 99% of cases those certificates are not needed for HTTPS communication and can be safely skipped
changed the title [-]SSLError(58, '[ASN1] nested asn1 error (_ssl.c:4174)')[/-][+]SSLError(58, '[ASN1] nested asn1 error (_ssl.c:4174)') and SSLError(0, 'not enough data: cadata does not contain a certificate (_ssl.c:4159)')[/+]on May 3, 2023
Blender recently introduced online extensions repositories and we have multiple reports from MS-Windows users that the [ASN1] nested asn1 error (_ssl.c:4035) error is preventing them from accessing HTTPS from Python.
Currently it's not clear:
If this is something that needs to be worked around (with run-time hacks).
If users are expected to resolve bad certificates (if so, it's not obvious how they would do this), I'm not using MS-Windows so I'm not clear on the details for how certificates are handled.
If users are expected to resolve bad certificates...
You can't expect users on Windows to do that.
For example, I have a root CA which is malformed according to the code that throws the error, but it was issued by our ministry of internal affairs and it is used as a root of trust for e-document signing and verification of our national ID cards.
So even though I can remove it I won't do it, because I need it for e-government sutff.
TL;DR — Python should just ignore what it can't use instead of blowing a gasket.
Would you be able to expand on whats happening here? The comment doesn't seem to match the check.
The workaround is not mine so please don't attribute it to me — it was proposed in a pull request by @pukkandan which @tiran was supposed to review but apparently never got to it, and which was since then closed by @serhiy-storchaka saying he can't reproduce (I think he never even tried to understand what the issue is).
I suggest you take it up with them for further clarifications.
As a matter of fact I am going to close this issue because I hate it when developers ignore bug reports for a whole year without as much as acknowledging them even if said acknowledgement means "won't fix".
Otherwise it's likely I'll have to create a new report as Blender users are currently hitting this bug, although it's something I'd need to investigate further so I could (setup an MS-Windows VM with a reproducible test case).
@levicki are you aware of steps to reproduce this bug? (a way to install a certificate that causes Python to fail with SSH connections).
There are too few core devs to give every issue the timely response we wish we could give.
This isn't "every issue", it's a very specific issue with a PR and if you do a casual Google search you will see that it's affecting quite a number of people using Python.
are you aware of steps to reproduce this bug? (a way to install a certificate that causes Python to fail with SSH connections).
Installing a not well-formed root certificate (one with a nested ASN.1 element which shouldn't be nested) in the Windows certificate store should be enough.
Activity
[-]SSLError(58, '[ASN1] nested asn1 error (_ssl.c:4174)')[/-][+]SSLError(58, '[ASN1] nested asn1 error (_ssl.c:4174)') and SSLError(0, 'not enough data: cadata does not contain a certificate (_ssl.c:4159)')[/+]ideasman42 commentedon Jul 18, 2024
Blender recently introduced online extensions repositories and we have multiple reports from MS-Windows users that the
[ASN1] nested asn1 error (_ssl.c:4035)error is preventing them from accessing HTTPS from Python.Currently it's not clear:
For reference:
https://projects.blender.org/blender/blender/issues/124731
levicki commentedon Jul 20, 2024
@ideasman42
You can't expect users on Windows to do that.
For example, I have a root CA which is malformed according to the code that throws the error, but it was issued by our ministry of internal affairs and it is used as a root of trust for e-document signing and verification of our national ID cards.
So even though I can remove it I won't do it, because I need it for e-government sutff.
TL;DR — Python should just ignore what it can't use instead of blowing a gasket.
ideasman42 commentedon Jul 28, 2024
@levicki thanks for the info.
From Blender's own PR to test this, the question was posted in response to the check for
x509_asn:Would you be able to expand on whats happening here? The comment doesn't seem to match the check.
levicki commentedon Jul 28, 2024
@ideasman42
The workaround is not mine so please don't attribute it to me — it was proposed in a pull request by @pukkandan which @tiran was supposed to review but apparently never got to it, and which was since then closed by @serhiy-storchaka saying he can't reproduce (I think he never even tried to understand what the issue is).
I suggest you take it up with them for further clarifications.
levicki commentedon Jul 28, 2024
As a matter of fact I am going to close this issue because I hate it when developers ignore bug reports for a whole year without as much as acknowledging them even if said acknowledgement means "won't fix".
terryjreedy commentedon Jul 28, 2024
There are too few core devs to give every issue the timely response we wish we could give.
ideasman42 commentedon Jul 28, 2024
@terryjreedy Could this report be re-opened?
Otherwise it's likely I'll have to create a new report as Blender users are currently hitting this bug, although it's something I'd need to investigate further so I could (setup an MS-Windows VM with a reproducible test case).
@levicki are you aware of steps to reproduce this bug? (a way to install a certificate that causes Python to fail with SSH connections).
levicki commentedon Jul 29, 2024
This isn't "every issue", it's a very specific issue with a PR and if you do a casual Google search you will see that it's affecting quite a number of people using Python.
Installing a not well-formed root certificate (one with a nested ASN.1 element which shouldn't be nested) in the Windows certificate store should be enough.
You can try with MUPCA Root from this page, it has been reported as problematic:
http://crl.mup.gov.rs/CA_sertifikati-lat.html
serhiy-storchaka commentedon Jul 29, 2024
I have reopened the original issue #79846. This issue is a duplicate of it.
Lexcon commentedon May 15, 2025