cURL for Windows using default settings won't check the revocation list in system

[chengr28]

Hi team,

Just received a security advisory about eMudhra, and then tested cURL for Windows (official build). It seems it won't check any revocations. I have already added listed 16 intermediate certificates to system local machine untrusted list manually before doing the test. Also tried Windows bundle curl, it uses Schannel totally and rejected the connections.
I'm not sure if this is expected behavior (may need some additional parameters?), so make a new discussion first instead of an issue.

Hope below information can help, thank you.

Windows 11 26H2 version 26300.9711
.\curl binary: 8.23.0_3 official build
curl.exe binary: system bundle

.\curl -V
curl 8.23.0 (x86_64-w64-mingw32) libcurl/8.23.0 LibreSSL/4.3.3 zlib/1.3.1.zlib-ng brotli/1.2.0 zstd/1.5.7 WinIDN libpsl/0.23.3 libssh2/1.11.1 nghttp2/1.70.0 ngtcp2/1.25.0 nghttp3/1.18.0 WinLDAP
Release-Date: 2026-10-14
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s rtsp scp sftp smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy HTTPSIG HTTPSRR IDN IPv6 Kerberos Largefile libz NativeCA proxy-HTTP3 PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd

.\curl -v "https://dv-g3b-aaa-emudhra.we-have-a-problem.com"
*   Trying 204.168.130.246:443...
*   Trying 54.39.60.141:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   Native: Windows System Stores ROOT+CA
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=dv-g3b-aaa-emudhra.we-have-a-problem.com
*   start date: Oct 20 02:22:41 2026 GMT
*   expire date: May  3 02:27:41 2027 GMT
*   issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
*   Certificate level 0: Public key type ? (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type ? (384/192 Bits/secBits), signed using sha256WithRSAEncryption
*   Certificate level 2: Public key type ? (2048/112 Bits/secBits), signed using sha1WithRSAEncryption
*   subjectAltName: "dv-g3b-aaa-emudhra.we-have-a-problem.com" matches cert's "dv-g3b-aaa-emudhra.we-have-a-problem.com"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to dv-g3b-aaa-emudhra.we-have-a-problem.com (204.168.130.246 port 443) from <hidden> port <hidden>
* using HTTP/1.x
> GET / HTTP/1.1
> Host: dv-g3b-aaa-emudhra.we-have-a-problem.com
> User-Agent: curl/8.23.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Content-Length: 15
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, HEAD, OPTIONS
< Access-Control-Allow-Headers: *
< Access-Control-Expose-Headers: *
< Access-Control-Max-Age: 86400
< Connection: close
< Cache-Control: no-store
<
<h1>hello</h1>
* shutting down connection #0

curl.exe -V
curl 8.21.0 (Windows) libcurl/8.21.0 Schannel zlib/1.3.2 WinIDN WinLDAP
Release-Date: 2026-06-24
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt mqtts pop3 pop3s smtp smtps telnet tftp ws wss
Features: alt-svc AsynchDNS HSTS HTTPS-proxy IDN IPv6 Kerberos Largefile libz SPNEGO SSL SSPI threadsafe Unicode UnixSockets`

curl.exe -v "https://dv-g3b-aaa-emudhra.we-have-a-problem.com"
*   Trying 204.168.130.246:443...
*   Trying 54.39.60.141:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* schannel: next InitializeSecurityContext failed: CRYPT_E_REVOKED (0x80092010) - The certificate is revoked.
* closing connection #0
curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOKED (0x80092010) - The certificate is revoked.

[benitoalba]

Hi @chengr28, with LibreSSL, curl 8.23.0 imports certificates from the Windows ROOT and CA stores into LibreSSL's own verifier. It doesn't consult the Windows Disallowed store or delegate verification to Windows' certificate chain engine. Adding --ca-native won't change that, your log already shows that certificate import is enabled.

Schannel uses Windows' native verification and honors its custom certificate security rules. It also performs CRL checks by default, as described in curl's certificate-verification documentation. For enforcing the Windows distrust settings you've configured, the Schannel build you already tested is the appropriate choice. No additional flag is needed to enable that behavior in your command.

If you need to stay with LibreSSL, --crlfile lets you supply issuer CRLs in PEM format. You'd need to obtain and maintain those CRLs separately; adding certificates to Windows' Untrusted Certificates list doesn't create CRL entries or make that list available to LibreSSL.

[vszakats]

This doesn't seem LibreSSL-specific, but applies to all OpenSSL/fork
TLS backends, also for all curl/libcurl builds configured (either at
build-time or at runtime) to use the native Windows CA roots.

Till there is support implemented for an automated negative list,
I suggest removing trust for the compromised roots via certmgr.msc.
This fixes it for all tools and libraries running on the machine. There
must be detailed guidance over the internet on how to do that, I think.

Another fix/workaround is to point such builds to a manual CA bundle,
via --caert (and siblings), that's been updated to exclude these roots.

As for using Schannel, its TLS capabilities and security properties may
be worse than that of of LibreSSL/OpenSSL depending on Windows
version and configuration, meaning switching to it may fix this issue,
but may be regressing elsewhere, depending.

[chengr28]

Hi benitoalba and vszakats,

Thanks for you help, then I will try to generate CRL or CA bundle for future test, till automatic revocation loading is ready.

However, in the past two days I found the way of removing CA from system is not working in Windows. It seems MS only revoked the intermediate certificates rather than CAs, they are still in trusted list at this time. The system will keep trust these CAs until I adding them to system untrusted list, even I delete them from all of two trusted lists (Trusted Root Certification Authorities & Third-Party Root Certification Authorities) in both certlm.msc & certmgr.msc.

Before doing new test, I have deleted all emSign... root certificates. At this stage, cURL rejected the connection (below the first quote). After that, I just opened the CA pem/crt file in Explorer (as I see, may include apps using SChannel or browsers connect to a website which contains the CA), suddenly the CA was "back" to trusted list. Now cURL loaded them from system and passed the certificate check (below the second quote).

This link said Windows will download and store CTL to registry automatically. It looks like when system "meets" certificates, it will check, then if that certificate is in registry CTL it will ADD it to trusted lists. This behavior breaks removing operations.

I think that the only way to stop connecting is negative list, not only CRL but also loading revocation list from system.

.\curl -v https://dv-g3b-emudhra.we-have-a-problem.com
*   Trying 54.39.60.141:443...
*   Trying 204.168.130.246:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   Native: Windows System Stores ROOT+CA
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=dv-g3b-emudhra.we-have-a-problem.com
*   start date: Oct 20 00:59:36 2026 GMT
*   expire date: May  3 01:04:36 2027 GMT
*   issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
*   Certificate level 0: Public key type ? (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type ? (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type ? (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   subjectAltName: "dv-g3b-emudhra.we-have-a-problem.com" matches cert's "dv-g3b-emudhra.we-have-a-problem.com"
* OpenSSL verify result: 14
* SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
* closing connection #0
curl: (60) SSL certificate OpenSSL verify result: unable to get local issuer certificate (20)
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the webpage mentioned above.

.\curl -v https://dv-g3b-emudhra.we-have-a-problem.com
*   Trying 54.39.60.141:443...
*   Trying 204.168.130.246:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
*   Native: Windows System Stores ROOT+CA
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / [blank] / UNDEF
* ALPN: server accepted http/1.1
* Server certificate:
*   subject: CN=dv-g3b-emudhra.we-have-a-problem.com
*   start date: Oct 20 00:59:36 2026 GMT
*   expire date: May  3 01:04:36 2027 GMT
*   issuer: C=NL; O=eMudhra BV; CN=EM DV TLS CA - G3B
*   Certificate level 0: Public key type ? (256/128 Bits/secBits), signed using ecdsa-with-SHA256
*   Certificate level 1: Public key type ? (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 2: Public key type ? (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   Certificate level 3: Public key type ? (384/192 Bits/secBits), signed using ecdsa-with-SHA384
*   subjectAltName: "dv-g3b-emudhra.we-have-a-problem.com" matches cert's "dv-g3b-emudhra.we-have-a-problem.com"
* OpenSSL verify result: 0
* SSL certificate verified via OpenSSL.
* Established connection to dv-g3b-emudhra.we-have-a-problem.com (54.39.60.141 port 443) from <hidden> port <hidden>
* using HTTP/1.x
> GET / HTTP/1.1
> Host: dv-g3b-emudhra.we-have-a-problem.com
> User-Agent: curl/8.23.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 200 OK
< Content-Type: text/plain; charset=utf-8
< Content-Length: 60
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET, HEAD, OPTIONS
< Access-Control-Allow-Headers: *
< Access-Control-Expose-Headers: *
< Access-Control-Max-Age: 86400
< Connection: close
< Cache-Control: no-store
<
Your client successfully connected to the site. That's bad!
* shutting down connection #0

[vszakats]

Hi benitoalba and vszakats,

Thanks for you help, then I will try to generate CRL or CA bundle for future test, till automatic revocation loading is ready.

Just a heads up, since this never came up before, nobody is working on this
at the moment and it's not on the horizon in the form of a TODO item for example.

I think an Issue or this discussion may help to shed light on this, to learn if it is
something a Windows app using the OS root store could or should do.

However, in the past two days I found the way of removing CA from system is not working in Windows. It seems MS only revoked the intermediate certificates rather than CAs, they are still in trusted list at this time. The system will keep trust these CAs until I adding them to system untrusted list, even I delete them from all of two trusted lists (Trusted Root Certification Authorities & Third-Party Root Certification Authorities) in both certlm.msc & certmgr.msc.

Have you tried not removing it, but right-clicking on it and disabling all uses
instead?

[benitoalba]

Thanks for clarifying, @vszakats.

@chengr28, for your CA bundle test, make sure to disable native CA loading explicitly:

.\curl.exe --no-ca-native --cacert .\filtered-ca-bundle.pem -v "https://dv-g3b-emudhra.we-have-a-problem.com"

--cacert alone doesn't disable the native store, so curl could still trust certificates imported from Windows. The filtered bundle would need to exclude the affected roots, which removes trust for their whole hierarchies and is broader than blocking the listed intermediates.

I should also clarify my earlier --crlfile suggestion: you'd need to obtain valid CRLs signed by the relevant issuers or authorized CRL signers. You can't generate those from the public certificate files alone, and a Windows distrust entry doesn't necessarily have a corresponding issuer CRL entry.

[chengr28]

Hi benitoalba and vszakats,
Thanks for you help, then I will try to generate CRL or CA bundle for future test, till automatic revocation loading is ready.

Just a heads up, since this never came up before, nobody is working on this at the moment and it's not on the horizon in the form of a TODO item for example.

I think an Issue or this discussion may help to shed light on this, to learn if it is something a Windows app using the OS root store could or should do.

I see, but before talking about loading revocation from system, we should find that how Windows handling the certificate verification. It looks like lots of modules can manage certificates, such as certlm.msc certmgr.msc certutil.exe registry CTL. We need to figure out their relationship.

I will keep update about this.

However, in the past two days I found the way of removing CA from system is not working in Windows. It seems MS only revoked the intermediate certificates rather than CAs, they are still in trusted list at this time. The system will keep trust these CAs until I adding them to system untrusted list, even I delete them from all of two trusted lists (Trusted Root Certification Authorities & Third-Party Root Certification Authorities) in both certlm.msc & certmgr.msc.

Have you tried not removing it, but right-clicking on it and disabling all uses instead?

It works! That is a good idea, cURL rejected the connection. In cert***.msc, select certificate -> right click -> properties -> select Disable all purposes for this certificate or unselect Server Authentication under Enable only the following purposes. Both of them could let cURL reports unable to get local issuer certificate (20) immediately.

I'm still surprised that removing the CA can't distrust it.

[chengr28]

Thanks for clarifying, @vszakats.

@chengr28, for your CA bundle test, make sure to disable native CA loading explicitly:

.\curl.exe --no-ca-native --cacert .\filtered-ca-bundle.pem -v "https://dv-g3b-emudhra.we-have-a-problem.com"

--cacert alone doesn't disable the native store, so curl could still trust certificates imported from Windows. The filtered bundle would need to exclude the affected roots, which removes trust for their whole hierarchies and is broader than blocking the listed intermediates.

I have tested and it seems no need to add --no-ca-native if have --cacert. Use .\curl.exe --cacert .\ca-bundle.pem -v "https://dv-g3b-emudhra.we-have-a-problem.com", cURL reports SSL Trust Anchors: CAfile: .\ca-bundle.pem (without Native: Windows System Stores ROOT+CA) and shows unable to get local issuer certificate (20) error. Once I have removed --cacert parameter, cURL always loads certificates from system and passes the verification.

I should also clarify my earlier --crlfile suggestion: you'd need to obtain valid CRLs signed by the relevant issuers or authorized CRL signers. You can't generate those from the public certificate files alone, and a Windows distrust entry doesn't necessarily have a corresponding issuer CRL entry.

Oh, that's a bad news. CRL needs to be signed, it's not an easy way to use to distrust these certificates. CRL may be designed for issuer, not for user.

[jay]

I've read this thread and I think you have a point. I'll add that in Windows there is a big difference between blocking and removing a root certificate. If a root certificate is removed in Windows and it is still trusted by Microsoft then Windows can tell it's missing from the root store and can re-import it the next time it sees it as an issuer. It takes place near instantaneously. Simply viewing a certificate can cause it. I assume it's using the Windows Update mechanism? but I tried it on an EOL Windows 8.1 device with the AAA root and saw the same thing: Delete AAA, simply view the certificate and it's re-imported by Windows. Yet that same device has not received the banned intermediates. Anyway, even if you add them manually as untrusted as you did here it's not helping which is why I think you have a point.

I'm proposing #23599 to address this by banning all the problem certificates. I consider this certificate breach an extraordinary case. What I'm proposing is not as thorough as checking a chain during verification for banned certificates but this is what I can offer with the time I have.

[vszakats]

I've read this thread and I think you have a point. I'll add that in Windows there is a big difference between blocking and removing a root certificate. If a root certificate is removed in Windows and it is still trusted by Microsoft then Windows can tell it's missing from the root store and can re-import it the next time it sees it as an issuer. It takes place near instantaneously. Simply viewing a certificate can cause it. I assume it's using the Windows Update mechanism? but I tried it on an EOL Windows 8.1 device with the AAA root and saw the same thing: Delete AAA, simply view the certificate and it's re-imported by Windows. Yet that same device has not received the banned intermediates. Anyway, even if you add them manually as untrusted as you did here it's not helping which is why I think you have a point.

Merely deleting a cert makes it impossible to tell if it was never added
or it was explicitly removed (unless deletion puts it on a 'deleted' list,
which is not the case here), thus I think it's expected that it gets (re)installed
if missing. The solution is to keep it there and mark it untrusted. This is not
a workaround. (same on macOS). It's also important to do this, because
curl is just one of the many possible programs that may rely on that list.

I'm proposing #23599 to address this by banning all the problem certificates. I consider this certificate breach an extraordinary case. What I'm proposing is not as thorough as checking a chain during verification for banned certificates but this is what I can offer with the time I have.

This makes sense regardless, I agree.

Are there perhaps other places where curl is in the loop to decide which
root it accepts? Maybe similar filtering could make sense there as well.

E.g. on macOS the default CA root list is a very obsolete one, that gets
reinstalled by Apple on every OS update, overwriting any edit.
It's a whack-a-mole to keep it updated and secure.
Ref: galadran/we-have-a-problem.com#45 (comment)

[jay]

Are there perhaps other places where curl is in the loop to decide which root it accepts? Maybe similar filtering could make sense there as well.

For example it would be more comprehensive to check a blacklist after verification, where essentially curl could veto the verification. Let's say the SSL lib has trusted that AAA root cert. Whether curl told it to or not is irrelevant for this example. The point is maybe you don't want to ban it, you just want to ban some bad intermediates it issued. How to handle that without a required revocation check, except walk the chain and check for banned CN or thumbprint etc.

This eMudhra situation is unusual because the certs are so trivial and both intermediates and roots can be skipped. Specifically because the roots can also be skipped #23599 works to address the specific issue in this thread. But it's a relatively narrow PR that won't stop those root or intermediate certificates being added elsewhere by some other location, with some outdated certificate bundle or OpenSSL hardcoded location.

[vszakats]

It's a weird situation where tools need to fix what CA bundle sources
are supposed to (and they clearly aren't; e.g. see today's macOS updates,
and lack of a Mozilla update in the Firefox 'release' channel). Also there are
likely many other quasi bundle-"distributions channels", many of them
possibly hidden or forgotten, therefore stale lists seem likely on many
devices.

If we block, a related technical question is how to identify what to block.
#23599 uses names, curl-for-win and curl-ca-bundle.crt (both via
mk-ca-bundle.pl) use SHA-256 fingerprints. Though as someone
reported last week, that's also not a perfect solution:
https://www.sonatype.com/blog/the-limits-of-fingerprint-blocklists-a-reproducible-java-certificate-bypass

[jay]

It appears MS has updates to remove the AAA and eMudhra G3 from the trusted roots https://github.com/TrustedRootProgram/Program-Requirements/blob/main/Announcements.md#microsoft-mitigations
GitHub Actions Windows images may not have these updates yet galadran/we-have-a-problem.com#171

[cpu]

If we block, a related technical question is how to identify what to block. #23599 uses names, curl-for-win and curl-ca-bundle.crt (both via mk-ca-bundle.pl) use SHA-256 fingerprints.

I strongly recommend blocking by the intermediate SPKI, either raw as we did in rustls/webpki or by the SHA256 digest of the SPKI as was done in BoringSSL and Go.

[icing]

If we use the Window Trust Store and Microsoft cannot be bothered to update that (and neither seems Apple), then fixing this in curl is probably the least of users problems.

Adding block lists into every software that does TLS seems like a well-intentioned, but insane approach to me.

[cpu]

I wasn't intending to start a debate about whether or not to do this, just providing input on the technical question that was posed about the best way, were it the path chosen.

For what it's worth my perspective is that this is a uniquely damaging situation and I don't expect to encounter a similar event in the near future that would necessitate expanding this blocking. It's harm reduction. I 1000% agree that Microsoft and Apple have let their users down, but I'm also unwilling to let users of software I maintain continue to be exposed to the risk when there's a mechanism I can ship that has few downsides and that will help protect them.

[icing]

Sorry, should have made the comment separate. Was not really directed at your input.

[cpu]

No worries, I also messed up and intended to thread my reply adjacent to vszakats's comment. The GH discussions UI is tricky. It's a crappy situation across the board and I don't fault anyone for asking why the responsibility to help is being pushed down lower and lower in the stack.

[vszakats]

New official curl Windows binaries 8.23.0_6 with Jay's filtering patch applied
downloadable from:
https://curl.se/windows/

[chengr28]

Thank you, connecting to tested websites returns unable to get local issuer certificate (20).

[chengr28]

Yes, adding negative list may not a perfect solution. I understand every tools have their focus and most of them which verify by their own only check positive list.

However, I think curl for Windows (not including Schannel backend) only checking positive list is not a good process, so I posted this discussion. As I know, different operation system / toolchain has different process to do certificate verification. MS provides Schannel to help programs to do TLS, of cause they perfer developers to use.

Curl has lots of TLS backends. It will import Windows's positive list when using OpenSSL/fork TLS backends, but as I see only importing positive list is not enough. Let's see MS's handling about the eMudhra situation: they only add bad intermediate certificates rather than removing / distrusting root certificates. It shows MS treats both positive and negative lists as a mechanism. Unfortunately, curl for Windows ignores the last one, that breaks the certificate verification which is designed by MS and gets this issue.

In the past few years, curl for Windows was used a pem file, it's ok, because as I see it follows the traditional practice. Then at some point, it was switched to import Windows ROOT+CA. If curl prefers to use OpenSSL/fork TLS backend in Windows and decided to trust Windows's certificate (use this mechanism), I think we should follow the design and implement the fully check, or delegate the verification process to system (Schannel?).

[vszakats]

Because this basically never happened before in the history of CA roots,
since last week the world is trying to figure out what to do in this
situation. Our tiny team and I personally have been dealing with this
24/7 for a week so far and every day there is a new machine, device,
service, PEM file that turns out to be not updated, or the updating
mechanism unclear, a black box or just broken. These include things made
by tiny companies like Apple, Microsoft, and OSes like macOS, Windows,
iOS, GitHub CI servers, and likely millions of other tools and
environments. Some of these give zero control to the owner of the device
(Apple iOS), and keeps being vulnerable, one week in.

So please give us some slack, and if you want to help, propose a patch
that we can review that fixes it the way you think is best.

Meanwhile, if you want to use a hand rolled PEM file, you can. If you
want to use Schannel, you can use the Windows-supplied copy. You may
also build it yourself in the exact specification you think will solve
this the best for your use-case.

Also the current official binary solves this by default regardless of how
the Windows env is managed, updated or not, or configured correctly
or not.

---

Re PEM:

I regard distributing PEMs a long-time nuisance and security disaster
waiting to happen, depending on where it's stored, how and where is it
acquired from, how it's verified, how is it securely updated and timely
so. The current situation is that Apple (5+ trillion company) ships a
copy from 2021 for every macOS user, OpenSSL to this day loads PEMs from
potentially insecure locations (CVE from 2019), curl tool loads them
insecurely on Windows by default (other options available, PR pending to
change default), GitHub macOS runners keep shipping with outdated ones
as of now (for both Apple and Homebrew). Debian python-certifi packages
still not updated in stable (edit: turns out they ship them, but also patch
certifi to use the system bundle, also in Ubuntu). Mozilla, the origin source
of the PEM, still not updated their canonical source repo. edit: MSYS2
ca-certificates packages also shipping 2 bad certs (just as Debian).

That said, sure, if someone manages to tick all the security boxes and
manually maintains a PEM file, it certainly can work, but in practice this
doesn't happen even in high profile cases, and I'd expect it to be all
over the place in many other cases.

[chengr28]

Thanks for your explanation, sorry for my impulsive reply. I just want to show the current process has possible issue and share my thoughts, not accusing or blaming or pressing.

Yes, we have a lot of ways to do verification, unfortunately all of them have their own focus and weakness. The reason why posting this discussion is hoping the tool can be better and keep robustness to avoid similar attacks in the furture.

[vszakats]

What's unclear to me, is how to handle a negative list; it can contain roots,
intermediates, so a verifier logic needs to apply it to these elemens of the
chain, not just remove them from the positive CA/ROOT list, though such
solution would be trivial to implement. So where to do the negative matching?
Does OpenSSL's API offer this out of the box? Or would it need to be done via
a custom callback? I haven't had the time to look into it and I'm also not a field
expert in this.

Is this done by other TLS backends that support native CAs on Windows?

FWIW the negative list on Windows is called "Untrusted".