SSLContext.load_verify_locations(cadata=<DER>) fails with [ASN1: NOT_ENOUGH_DATA] when linked against OpenSSL 3.0.21+

Bug report

Bug description:

When CPython is linked against OpenSSL 3.0.21 (and likely any release carrying the CVE-2026-34180 ASN.1 hardening), SSLContext.load_verify_locations(cadata=) raises:

ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:NNNN)

even for a single, perfectly valid DER certificate. On Windows this breaks ssl.create_default_context() outright, because SSLContext._load_windows_store_certs() loads the system trust store via cadata=. The practical effect is that all default-context HTTPS fails (e.g. importing aiohttp, which builds a default context at import time, crashes).

Reproducer (platform-independent)

import ssl
pem = ssl.get_server_certificate(("www.python.org", 443))
der = ssl.PEM_cert_to_DER_cert(pem)

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_CLIENT)
ctx.load_verify_locations(cadata=der)   # raises [ASN1: NOT_ENOUGH_DATA] on OpenSSL 3.0.21+
print("loaded OK")

OpenSSL 3.0.15 (and earlier): prints loaded OK.
OpenSSL 3.0.21: raises ssl.SSLError: [ASN1: NOT_ENOUGH_DATA].

The certificate itself is fine — calling d2i_X509 directly against the same libcrypto-3.dll parses it successfully; only the path through _ssl fails.

Root cause
In Modules/_ssl.c, _add_ca_certs() reads certs in a loop until d2i_X509_bio() returns NULL, then inspects the leftover error to distinguish a clean end-of-buffer from a real failure. It only accepts ASN1_R_HEADER_TOO_LONG as the benign EOF marker:

} else if ((filetype == SSL_FILETYPE_ASN1) &&
                (ERR_GET_LIB(err) == ERR_LIB_ASN1) &&
                (ERR_GET_REASON(err) == ASN1_R_HEADER_TOO_LONG)) {
    /* EOF ASN1 file, not an error */
    ERR_clear_error();
    retval = 0;
}

OpenSSL 3.0.21 now reports end-of-buffer as ASN1_R_NOT_ENOUGH_DATA (reason 142) instead of ASN1_R_HEADER_TOO_LONG. That reason isn't whitelisted, so the function falls through to the generic error branch and raises, discarding the load. Confirmed by reading ERR_peek_last_error() after the final d2i_X509_bio() on a single-cert buffer: 0x0680008E = asn1 ... not enough data.

Proposed fix
Treat ASN1_R_NOT_ENOUGH_DATA as a clean EOF alongside ASN1_R_HEADER_TOO_LONG:

} else if ((filetype == SSL_FILETYPE_ASN1) &&
                (ERR_GET_LIB(err) == ERR_LIB_ASN1) &&
                ((ERR_GET_REASON(err) == ASN1_R_HEADER_TOO_LONG) ||
                 (ERR_GET_REASON(err) == ASN1_R_NOT_ENOUGH_DATA))) {
    /* EOF ASN1 buffer, not an error (OpenSSL 3.0.21+ reports the
       end-of-data condition as ASN1_R_NOT_ENOUGH_DATA). */
    ERR_clear_error();
    retval = 0;
}

With this change, load_verify_locations(cadata=...) succeeds, the Windows store loads fully, and TLS verification works again.

Environment
CPython 3.11.15 (self-built, Windows x64, MSVC), linked against self-compiled OpenSSL 3.0.21.
Windows 11.
Also expected to affect any build/version of CPython linked against OpenSSL ≥ 3.0.21 (or whichever release introduced the reason-code change), on any platform, for the DER cadata path.

CPython versions tested on:

3.11

Operating systems tested on:

Windows

When CPython is linked against OpenSSL 3.0.21 (and likely any release carrying the GHSA-3c8f-qq7h-7qv6 ASN.1 hardening)

Note: I cannot reproduce the issue on Fedora 44 with OpenSSL 3.5.5.

When CPython is linked against OpenSSL 3.0.21 (and likely any release carrying the GHSA-3c8f-qq7h-7qv6 ASN.1 hardening)

Note: I cannot reproduce the issue on Fedora 44 with OpenSSL 3.5.5.

likely to happen for you in 3.5.7

@pablogsal

This seems to be a 3.11-only issue that's already been resolved in 3.12. I recently started hitting it on my private Windows builds.

In 3.12, a was_bio_eof flag was added and is assigned BIO_eof(biobuf). Then when we break out, the code snippet mentioned in the original report checks that flag rather than relying on specific error codes.

@pablogsal How do you feel about fixing this in 3.11? It's not strictly a security issue in itself, but without it, it's not feasible to use newer OpenSSL (I haven't tested with newer than OpenSSL 3.0.21), at least on Windows, possibly other platforms too.

Here are the test results for this issue across various Fedora images and Python versions

Fedora Linux 39 (Container Image)
Python 3.8.20 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.9.20 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.10.15 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.11.10 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.12.7 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.13.0 - OK
OpenSSL 3.1.4 24 Oct 2023
Python 3.14.0a1 - OK
OpenSSL 3.1.4 24 Oct 2023

Fedora Linux 40 (Container Image)
Python 3.8.20 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.9.21 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.10.17 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.11.12 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.12.10 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.13.3 - OK
OpenSSL 3.2.4 11 Feb 2025
Python 3.14.0a7 - OK
OpenSSL 3.2.4 11 Feb 2025

Fedora Linux 41 (Container Image)
Python 3.8.20 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.9.25 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.10.19 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.11.14 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.12.12 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.13.9 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.14.0 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.15.0a2 - OK
OpenSSL 3.2.6 30 Sep 2025

Fedora Linux 42 (Container Image)
Python 3.9.25 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.10.20 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.11.15 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.12.13 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.13.13 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.14.5 - OK
OpenSSL 3.2.6 30 Sep 2025
Python 3.15.0b1 - OK
OpenSSL 3.2.6 30 Sep 2025

Fedora Linux 43 (Container Image)
Python 3.9.25
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4192)
OpenSSL 3.5.7 9 Jun 2026
Python 3.10.20
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4028)
OpenSSL 3.5.7 9 Jun 2026
Python 3.11.15
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4045)
OpenSSL 3.5.7 9 Jun 2026
Python 3.12.13 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.13.14 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.14.5 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.15.0b2 - OK
OpenSSL 3.5.7 9 Jun 2026

Fedora Linux 44 (Container Image)
Python 3.9.25
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4192)
OpenSSL 3.5.7 9 Jun 2026
Python 3.10.20
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4028)
OpenSSL 3.5.7 9 Jun 2026
Python 3.11.15
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4045)
OpenSSL 3.5.7 9 Jun 2026
Python 3.12.13 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.13.14 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.14.6 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.15.0b2 - OK
OpenSSL 3.5.7 9 Jun 2026

Fedora Linux 45 (Container Image Prerelease)
Python 3.9.25
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4192)
OpenSSL 3.5.7 9 Jun 2026
Python 3.10.20
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4028)
OpenSSL 3.5.7 9 Jun 2026
Python 3.11.15
ssl.SSLError: [ASN1: NOT_ENOUGH_DATA] not enough data (_ssl.c:4045)
OpenSSL 3.5.7 9 Jun 2026
Python 3.12.13 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.13.14 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.14.6 - OK
OpenSSL 3.5.7 9 Jun 2026
Python 3.15.0b2 - OK
OpenSSL 4.0.1 9 Jun 2026

upd: added ssl.OPENSSL_VERSION

Here are the test results for this issue across various Fedora images

Can you include the OpenSSL versions? That's what is relevant here, though it does seem likely that it's the same issue.

We need RM agreement to treat this as a security fix, since it isn't really a security issue.

It's now hitting 3.10 & 3.11 buildbots.

We might see this in Fedora for OpenSSL 3.5.7+

https://koschei.fedoraproject.org/package/python3.11?collection=f44
https://koschei.fedoraproject.org/package/python3.10?collection=f44

acfe02f looks like a change that could explain why this no longer impacts 3.12+

EDIT: Yes, I can confirm that backporting that to 3.11 makes it pass the tests.

acfe02f looks like a change that could explain why this no longer impacts 3.12+

Yes, that's the change. I backported it to my own (private) fork of 3.11 and it's working fine so far (hasn't made it into production anywhere, but it's passing the tests that were failing without it).

00489: Use BIO_eof to detect EOF for SSL_FILETYPE_ASN1

Mark centos9s jobs non-voting

Update git submodules

fix: download ansible collections using curl, not Python SSL

Ran into this issue on

Rocky Linux 9.8
Python 3.9.25
openssl-3.5.5-5.el9_8.x86_64
openssl-libs-3.5.5-5.el9_8.x86_64

Have been looking around, but not sure who is fixing this ? Python ? or openssl ?

Would help to know what package update to watch for.

In RHEL (and hence I assume also in Rocky) it should be both.

OSAC-2801: Scope validate_certs:false to k3s_controller's plain-HTTP …

That's an unnecessarily long way to say "me too".

What we need is the release manager to say whether we can backport our own fix or not. No number of paragraphs are going to help with that.

OSAC-2801: Work around ansible-galaxy TLS regression in tooling-check…

GitHub Release 다운로드에서 CVE-2026-34180 관련 SSL 검증 오류 임시 우회

core: openssl: fix python ptest errors

Hit this on Windows 11 25H2 with Python 3.11.4
Solution is to upgrade Python or to avoid using pip-system-certs.

The RC appears to be an upstream OpenSSL fix for asn1_d2i_read_bio reads too many bytes · Issue #22704 · openssl/openssl / CVE-2026-34180 / CVE-2026-34180 - GitHub Advisory Database ; this broke the API contract for OpenSSL's ASN.1-based certificate parsing on Windows.

This faulty fix was backported to a bunch of OpenSSL releases, and also actually fixed in a following release by openssl/openssl#31807:

Branch	Problematic commit (shipped)	First affected release	Fix commit	First fixed release
3.0	`77f8454895`	3.0.21	`430472298fec`	3.0.22
3.1	Not affected — never backported to this branch	n/a	n/a	n/a
3.2	Not affected — never backported to this branch	n/a	n/a	n/a
3.3	Not affected — never backported to this branch	n/a	n/a	n/a
3.4	`b386c02440`	3.4.6	`07e39bbb27f8`	3.4.7
3.5	`738688d762`	3.5.7	`3687ff719503`	3.5.8
3.6	`e734e38ab6`	3.6.3	`eec366c60280`	3.6.4
4.0	`445b06163b`	4.0.1 (4.0.0 was clean)	`4360d537e8`	4.0.2

Per thread, it looks like Python 3.12+ is more defensive about this API change. Absent a fix for Python 3.11 and earlier, it looks like the best way forward:

Move to Python 3.12+
Move to one of OpenSSL 3.0.22, 3.4.7, 3.5.8, 3.6.4, or 4.0.2

Navigation Menu

Repository navigation

SSLContext.load_verify_locations(cadata=<DER>) fails with [ASN1: NOT_ENOUGH_DATA] when linked against OpenSSL 3.0.21+ #151504

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

8 remaining items

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

SSLContext.load_verify_locations(cadata=<DER>) fails with [ASN1: NOT_ENOUGH_DATA] when linked against OpenSSL 3.0.21+ #151504

Description

Bug report

Bug description:

CPython versions tested on:

Operating systems tested on:

Activity

vstinner commented on Jun 15, 2026

nkfilis commented on Jun 17, 2026

zooba commented on Jun 22, 2026

po1nt-1 commented on Jun 23, 2026

zooba commented on Jun 23, 2026

encukou commented on Jun 30, 2026

hroncok commented on Jul 1, 2026

hroncok commented on Jul 1, 2026

zooba commented on Jul 1, 2026

8 remaining items

1rcjoy commented on Jul 16, 2026

hroncok commented on Jul 16, 2026

zooba commented on Jul 20, 2026

cidermole commented on Aug 14, 2026

samatjain commented on Sep 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions