Default using Windows Schannel for SSL/TLS on Windows #2116
Conversation
|
I noticed that there is |
|
@solarispika sorry for the delay. According to this comment #1978 (comment), you mentioned you ended up bypassing CRL in your production server. Do you think that the current pull request which doesn't have the bypassing code will affect a number of Windows users? If not many, I don't mind merging this code. But it has a risk to affect many users, I would like you to implement a feature flag like |
|
Hi @yhirose I am not sure how many of them will be, possibly the number being proportional to users located in China. |
|
@solarispika , (1) If a number of users will be affected by this, I prefer making it an opt-in feature with (2) But if we expect only few users will be affected, we can enable this feature by the default and uses can disable it with I prefer #2. |
solarispika
force-pushed
the
default-using-windows-schannel
branch
from
f97e72c to
4661630
Compare
|
@yhirose |
solarispika
force-pushed
the
default-using-windows-schannel
branch
from
4661630 to
bb7c085
Compare
|
Could you please take a look at unit test errors on 'test / windows with SSL (pull_request)'? |
|
Sure, it looks like #2169 saves openssl errors which I didn't notice. |
|
I found that it is hard to map errors between Win32 API and OpenSSL. What do you recommend? Is it proper to mask those checks when Schannel is used? |
|
@solarispika I actually don't know what do to. Could you please investigate why those errors occur before making any change? |
|
@yhirose As those member functions are defined for OpenSSL, it is inappropriate for me to use it directly for errors coming from Windows API. |
|
|
||
| if (verification_status == SSLVerifierResponse::NoDecisionMade) { | ||
| #if !defined(_WIN32) || \ | ||
| defined(CPPHTTPLIB_DISABLE_WINDOWS_AUTOMATIC_ROOT_CERTIFICATES_UPDATE) |
There was a problem hiding this comment.
@solarispika why does this check need to be skipped when CPPHTTPLIB_DISABLE_WINDOWS_AUTOMATIC_ROOT_CERTIFICATES_UPDATE is defined?
There was a problem hiding this comment.
I think this check and check from Windows are both checking certificate, so it is a either-or behavior.
So, if Windows automatic root certificate updates is disabled, then using old behavior; otherwise, use new one.
Am I missing something?
|
@solarispika it looks that the Windows code returns only |
@yhirose I have no experience using those APIs, so I can't give any suggestions on it now. |
|
@solarispika @yhirose I have a project that I think would benefit from these changes. I may have some time to help out if there is anything else that is needed to get this merged. Is there anything specific that you have in mind? I did some testing with this change and updating "normal" certificates on my machine. I saw it use updated certificates automatically as expected. I did not specifically test with root certificates yet though, so I did not yet see that working, but it seems like it should. I see that a couple of the checks failed, but the logs are now gone, so I can't tell what went wrong. I didn't see a way to manually re-run those actions. I was thinking of making a commit change to have the actions run again, but I didn't want to mess with this PR without warning or make my own fork and PR just to see the logs. |
|
Thanks for any help someone will not stop attacking me and I think it's
time for there computer privileges to go away for life.
Me
…On Mon, Nov 17, 2025, 3:58 PM Brett Lesnau ***@***.***> wrote:
*BLesnau* left a comment (yhirose/cpp-httplib#2116)
<#2116 (comment)>
@solarispika <https://github.com/solarispika> @yhirose
<https://github.com/yhirose> I have a project that I think would benefit
from these changes. I may have some time to help out if there is anything
else that is needed to get this merged. Is there anything specific that you
have in mind? I did some testing with this change and updating "normal"
certificates on my machine. I saw it use updated certificates automatically
as expected. I did not specifically test with root certificates yet though,
so I did not yet see that working, but it seems like it should.
I see that a couple of the checks failed, but the logs are now gone, so I
can't tell what went wrong. I didn't see a way to manually re-run those
actions. I was thinking of making a commit change to have the actions run
again, but I didn't want to mess with this PR without warning or make my
own fork and PR just to see the logs.
—
Reply to this email directly, view it on GitHub
<#2116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BZQJ6WZFPAO2IEPNMGYGLNL35IZGLAVCNFSM6AAAAABZT2WDS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBTHAYDIOBTGY>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I was trying to test some of this myself, and I think I may not know enough about how to test it properly. I tried with self-signed certs. I tried reproducing the problem first, but the certificate was always available as long and I closed and reopened my app that uses Any tips on how to test it would be great. Even if testing isn't straightforward, I'm still good with helping to get this PR moving closer to being merged. |
|
No clue thanks for the help
MY DIC
…On Tue, Nov 18, 2025, 3:51 PM Brett Lesnau ***@***.***> wrote:
*BLesnau* left a comment (yhirose/cpp-httplib#2116)
<#2116 (comment)>
I was trying to test some of this myself, and I think I may not know
enough about how to test it properly. I tried with self-signed certs. I
tried reproducing the problem first, but the certificate was always
available as long and I closed and reopened my app that uses cpp-httplib
after I imported the cert. I tried importing it specifically as a root cert
for LocalMachine, but it is always being propogated to both LocalMachine
and CurrentUser no matter how I try to import the cert. Maybe I am going
about the testing all wrong. I'm pretty new to this with the certs.
Any tips on how to test it would be great. Even if testing isn't
straightforward, I'm still good with helping to get this PR moving closer
to being merged.
—
Reply to this email directly, view it on GitHub
<#2116 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/BZQJ6W7WPRCWIPHDVBZFSEL35OBFVAVCNFSM6AAAAABZT2WDS6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKNBZGUYDQMZRGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
@BLesnau The error come from ssl and openssl errors are not set correspondingly if I remember correctly. |
solarispika
force-pushed
the
default-using-windows-schannel
branch
from
bb7c085 to
30669cc
Compare
This commit enables Windows Schannel for certificate verification on Windows platforms, providing automatic root certificate updates from Windows Update. Key changes: - Added Windows Schannel certificate verification using CertGetCertificateChain and CertVerifyCertificateChainPolicy APIs - Implemented wincrypt_error() and wincrypt_chain_error() to expose Windows certificate errors alongside existing OpenSSL error fields - Clear ssl_openssl_error before Windows verification to provide unambiguous error source indication (0 means Windows error, non-zero means OpenSSL error) - Updated tests with platform-specific assertions for Windows vs OpenSSL errors - Added comprehensive Windows certificate error documentation to README Certificate verification flow on Windows: 1. OpenSSL performs TLS handshake (can set ssl_error) 2. Windows Schannel verifies certificate chain (sets wincrypt_error and wincrypt_chain_error) 3. Users check wincrypt_error() for Windows-specific error codes like CERT_E_EXPIRED, CERT_E_UNTRUSTEDROOT, CERT_E_REVOKED, etc. Feature can be disabled with CPPHTTPLIB_DISABLE_WINDOWS_AUTOMATIC_ROOT_CERTIFICATES_UPDATE or by setting HTTPLIB_USE_WINDOWS_AUTOMATIC_ROOT_CERTIFICATES_UPDATE=OFF in CMake. Fixes yhirose#1978 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
solarispika
force-pushed
the
default-using-windows-schannel
branch
from
30669cc to
b8e2cba
Compare
|
@solarispika @yhirose As part of looking at this PR, I was trying to understand more about how cpp-httplib does certain things (very new to me). Feel free to tell me to bring this discussion elsewhere if it's not related enough to this PR. Without these Schannel changes, does cpp-httplib use the certs on Windows already or is it only the certs that are part of OpenSSL when it was compiled? Based on my testing, it does look like the Windows certs are retrieved when the client initializes. If cpp-httplib does use the Windows certs at init time, is there any specific code I should look at to understand it better? Edit: I think I found the relevant code with the |
4 participants
Follow
https://learn.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-certgetcertificatechain for related flags.
Closes #1978