Repository navigation
fix(tls): trust every certificate in a CA bundle - #393
Open
mvandeberg wants to merge 1 commit into
Open
mvandeberg wants to merge 1 commit into
mvandeberg wants to merge 1 commit into
Conversation
|
An automated preview of the documentation is available at https://393.corosio.prtest3.cppalliance.org/index.html If more commits are pushed to the pull request, the docs will rebuild at the same URL. 2026-10-13 22:04:49 UTC |
|
GCOVR code coverage report https://393.corosio.prtest3.cppalliance.org/gcovr/index.html Build time: 2026-10-13 22:20:35 UTC |
The OpenSSL engine read only the first certificate of each trust-anchor entry, so load_verify_file() on a multi-certificate bundle silently trusted one root. Read until the PEM data is exhausted, as Asio does, and fail setup on any certificate that does not parse. WolfSSL already loads every certificate it can use from a bundle and fails only when none load. Keep that: WolfSSL rejects roots that system bundles ship (expired ones under peer verification, serial number 0 on some builds), and failing on those would reject the whole store. An empty buffer returned 0 rather than an error code, which let empty CA data pass setup; map it to an error. Correct the TLS documentation that contradicted the implementation: - drop the HTTPS example warning that set_default_verify_paths() loads nothing, the tutorial note that it contributes nothing, and both first-certificate notes - state that hostname verification runs only under the peer or require_peer verify mode, while an IP literal on a WolfSSL build without IP-literal support fails under every mode - on WolfSSL without HAVE_CRL, only a non-disabled revocation policy fails the handshake; a CRL under the disabled policy is ignored - list every WolfSSL build-dependent feature with its configure switch - describe per backend what set_default_verify_paths() loads and how a CA bundle with a bad certificate is handled - setters report only files that cannot be opened and malformed ALPN names; most settings are captured at the first handshake, while callbacks are read later - drop backends that do not exist (mbedTLS, Schannel) - split the protocol_versions snippet, whose inverted version window could never handshake, into two contexts Closes cppalliance#350
mvandeberg
force-pushed
the
fix/350-stale-tls-warnings
branch
from
October 13, 2026 21:57
e6b4006 to
35863cb
Compare
mvandeberg
marked this pull request as ready for review
October 14, 2026 14:50
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The OpenSSL engine read only the first certificate of each trust-anchor entry, so load_verify_file() on a multi-certificate bundle silently trusted one root. Read until the PEM data is exhausted, as Asio does, and fail setup on any certificate that does not parse.
WolfSSL already loads every certificate it can use from a bundle and fails only when none load. Keep that: WolfSSL rejects roots that system bundles ship (expired ones under peer verification, serial number 0 on some builds), and failing on those would reject the whole store. An empty buffer returned 0 rather than an error code, which let empty CA data pass setup; map it to an error.
Correct the TLS documentation that contradicted the implementation:
Closes #350