Files
node/lib/internal
Tim Perry c59cd6b046 tls: fix authorized state on no-cert TLS1.3 client cert resumption
Previously if you used TLS 1.3 and the server requested a client cert,
but the client didn't send one, and you used rejectUnauthorized:false
the resumed session would report authorized=true. This doesn't match TLS
1.2 behaviour or make any sense, and was purely an artifact of our
internal logic for handling TLS 1.3 resumption details. We now correctly
report the authorization state and/or error from the original connection
in all cases, with a matrix test that fully checks the invariant:
authorized state after resume should always match the initial state.

Signed-off-by: Tim Perry <pimterry@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/64677
Reviewed-By: James M Snell <jasnell@gmail.com>
2026-08-08 15:05:06 +00:00
..
2026-07-24 14:00:18 +00:00
2026-08-01 06:15:08 +00:00
2026-07-25 23:56:46 -07:00
…
2026-07-25 23:56:46 -07:00
…
…
2026-08-06 09:25:51 +00:00
2026-07-24 14:00:18 +00:00
…
2026-01-30 19:46:49 +00:00
2026-07-24 14:00:18 +00:00
2026-08-05 13:57:32 +00:00
…
…
2026-07-24 14:00:18 +00:00
…
2026-05-30 09:05:23 +00:00
…

Internal Modules

The modules located in lib/internal directory are exclusively meant for internal usage within the Node.js core. They are not intended to be accessed via user modules require(). These modules may change at any point in time. Relying on these internal modules outside the core is not supported and can lead to unpredictable behavior.

In certain scenarios, accessing these internal modules for debugging or experimental purposes might be necessary. Node.js provides the --expose-internals flag to expose these modules to userland code. This flag only exists to assist Node.js maintainers with debugging internals. It is not meant for use outside the project.