Skip to content

fix(tls): trust every certificate in a CA bundle - #393

Open
mvandeberg wants to merge 1 commit into
cppalliance:developfrom
mvandeberg:fix/350-stale-tls-warnings
Open

mvandeberg wants to merge 1 commit into
cppalliance:developfrom
mvandeberg:fix/350-stale-tls-warnings

Conversation

@mvandeberg

Copy link
Copy Markdown
Contributor

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
  • 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; configuration is captured at the first handshake
  • drop backends that do not exist (mbedTLS, Schannel)
  • split the protocol_versions snippet, whose inverted version window could never handshake, into two contexts

Closes #350

@cppalliance-bot

cppalliance-bot commented Oct 13, 2026 •

Copy link
Copy Markdown

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

@cppalliance-bot

cppalliance-bot commented Oct 13, 2026 •

Copy link
Copy Markdown

GCOVR code coverage report https://393.corosio.prtest3.cppalliance.org/gcovr/index.html
LCOV code coverage report https://393.corosio.prtest3.cppalliance.org/genhtml/index.html
Coverage Diff Report https://393.corosio.prtest3.cppalliance.org/diff-report/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
mvandeberg force-pushed the fix/350-stale-tls-warnings branch from e6b4006 to 35863cb Compare October 13, 2026 21:57
@mvandeberg
mvandeberg marked this pull request as ready for review October 14, 2026 14:50

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Backlog

Development

Successfully merging this pull request may close these issues.

docs: remove stale TLS warnings that contradict the implemented verification

2 participants