Skip to content

tls: add OpenSSL CA lookup to getCACertificates#64269

Open
Archkon wants to merge 1 commit into
nodejs:mainfrom
Archkon:tls
Open

tls: add OpenSSL CA lookup to getCACertificates#64269
Archkon wants to merge 1 commit into
nodejs:mainfrom
Archkon:tls

Conversation

@Archkon

@Archkon Archkon commented Jul 3, 2026

Copy link
Copy Markdown
Contributor

Fixes: #64258

@nodejs-github-bot

Copy link
Copy Markdown
Collaborator

Review requested:

  • @nodejs/crypto
  • @nodejs/net

@nodejs-github-bot nodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run. tls Issues and PRs related to the tls subsystem. typings labels Jul 3, 2026
Comment thread src/crypto/crypto_context.cc
Comment thread doc/api/tls.md Outdated
@Archkon Archkon requested a review from joyeecheung July 4, 2026 03:35
@Archkon Archkon force-pushed the tls branch 2 times, most recently from 3bea054 to e73c4ad Compare July 4, 2026 18:32
@Archkon

Archkon commented Jul 5, 2026

Copy link
Copy Markdown
Contributor Author

@joyeecheung
I’m not sure whether we should add support for the OpenSSL CA flag when developers pass the default type.

The existing behavior with OpenSSL CAs is that, during TLS connection setup, OpenSSL performs hash-based lookups for certificates. However, that behavior is not synchronized with what tls.getCACertificates('default') returns.

Another possibility would be to allow the default type to accept a second lookup argument, but that seems to duplicate the purpose of adding a separate openssl type.

Could you review the code by the way ? I really don't know how to support subject parse which maybe implement a
OpenSSL/RFC2253 subject parser ?

@joyeecheung

Copy link
Copy Markdown
Member

Another possibility would be to allow the default type to accept a second lookup argument, but that seems to duplicate the purpose of adding a separate openssl type.

There's also NODE_EXTRA_CA_CERTS to consider:

// Flags: --use-openssl-ca
tls.getCACertificates('default');   // Either warn or error about no issuer name to filter for
tls.getCACertificates('default', cert);  // Does not warn and perform a similar hash lookup for system certs, + extra certs from NODE_EXTRA_CA_CERTS if any
tls.getCACertificates('openssl', cert);  // Similar, but no certs from NODE_EXTRA_CA_CERTS

@Archkon

Archkon commented Jul 7, 2026

Copy link
Copy Markdown
Contributor Author

Another possibility would be to allow the default type to accept a second lookup argument, but that seems to duplicate the purpose of adding a separate openssl type.

There's also NODE_EXTRA_CA_CERTS to consider:

// Flags: --use-openssl-ca
tls.getCACertificates('default');   // Either warn or error about no issuer name to filter for
tls.getCACertificates('default', cert);  // Does not warn and perform a similar hash lookup for system certs, + extra certs from NODE_EXTRA_CA_CERTS if any
tls.getCACertificates('openssl', cert);  // Similar, but no certs from NODE_EXTRA_CA_CERTS

@joyeecheung
So are we only allowing this API to accept certificates as valid arguments, while dropping support for subject name ? And one more thing, I need calrification about how to deal with developers who call tls.getCACertificates('openssl', cert);without --use-openssl-ca as flag to pass? allow or not?

@codecov

codecov Bot commented Jul 10, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 85.62500% with 23 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.24%. Comparing base (6eff679) to head (d700f3c).
⚠️ Report is 3 commits behind head on main.

Files with missing lines Patch % Lines
src/crypto/crypto_context.cc 74.39% 10 Missing and 11 partials ⚠️
lib/tls.js 97.43% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main   #64269      +/-   ##
==========================================
+ Coverage   90.23%   90.24%   +0.01%     
==========================================
  Files         741      741              
  Lines      241342   241527     +185     
  Branches    45474    45522      +48     
==========================================
+ Hits       217767   217972     +205     
+ Misses      15123    15101      -22     
- Partials     8452     8454       +2     
Files with missing lines Coverage Δ
lib/tls.js 93.55% <97.43%> (+0.41%) ⬆️
src/crypto/crypto_context.cc 72.52% <74.39%> (+0.24%) ⬆️

... and 39 files with indirect coverage changes

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@joyeecheung

Copy link
Copy Markdown
Member

So are we only allowing this API to accept certificates as valid arguments, while dropping support for subject name ?

I think starting with a certificate makes sense (or matches a bit more with what you'd expect from OpenSSL). If anyone requests support for subject name string that can be added later.

I need calrification about how to deal with developers who call tls.getCACertificates('openssl', cert);without --use-openssl-ca as flag to pass? allow or not?

I think it's fine to allow that to work without the flag. It should return "what would've been used if the flag is used".

@Archkon Archkon changed the title tls: include OpenSSL CAs in default CA list tls: add OpenSSL CA lookup to getCACertificates Jul 11, 2026
When OpenSSL is the effective default CA store, TLS clients load issuers
from OpenSSL's default certificate file and hashed directories. However,
tls.getCACertificates('default') did not expose the same store, so its
result did not reflect the certificates available to TLS verification.

OpenSSL certificate directories are indexed by subject hash and are
resolved for a specific issuer. They cannot be represented reliably by
enumerating every file in those directories. Add a cert argument and use
X509_STORE_CTX_get1_issuer() so getCACertificates() follows OpenSSL's
issuer lookup behavior.

Add the "openssl" type to query only OpenSSL's default store. When
OpenSSL is the effective default, make "default" query Node.js' complete
default store so NODE_EXTRA_CA_CERTS is considered as well. Require a
certificate for these lookups because there is no issuer key otherwise.

Accept PEM strings, PEM or DER ArrayBufferViews, and X509Certificate
objects. Detect the effective OpenSSL store so build-time
--openssl-use-def-ca-store configurations behave the same as
--use-openssl-ca. Also split path-delimited OpenSSL certificate
directories when loading system CA certificates.

Add regression coverage for certificate files, hashed directories,
extra CAs, supported input types, invalid input, default-store overrides
,and OpenSSL-backed build configurations.

Signed-off-by: Archkon <180910180+Archkon@users.noreply.github.com>
@Archkon Archkon force-pushed the tls branch 2 times, most recently from d700f3c to 802bc85 Compare July 11, 2026 10:42
@Archkon

Archkon commented Jul 11, 2026

Copy link
Copy Markdown
Contributor Author

@joyeecheung
Done,Could you review the code when avaliable? Thanks!

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

Labels

c++ Issues and PRs that require attention from people who are familiar with C++. crypto Issues and PRs related to the crypto subsystem. needs-ci PRs that need a full CI run. tls Issues and PRs related to the tls subsystem. typings

Projects

None yet

Development

Successfully merging this pull request may close these issues.

tls.getCACertificates("default") always returns an empty list when using --use-openssl-ca

3 participants