René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"tls: server getPeerCertificate(true) drops the peer certificate chain since v26.8.0 (regressed by #64677)","articleBody":"### Version\n\n`v26.8.0` and up. `v26.7.0` is unaffected. Reproduces on current `main`.\n\n### Platform\n\n```text\nLinux 6.18.35.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC x86_64 GNU/Linux\n```\n\nAlso reproduced on GitHub Actions `ubuntu-latest`. OpenSSL is 3.5.7.\n\n### Subsystem\n\ntls\n\n### What steps will reproduce the bug?\n\nOn the server side of a mutual-TLS connection, `socket.getPeerCertificate(true)` no longer returns the client certificate's issuer chain. The leaf is returned fully populated, but `issuerCertificate` is `undefined`, even though the client presented `[leaf, intermediate]` and the socket is `authorized`.\n\nHere is a repo script that creates a root -> intermediate -> client chain with `openssl`, then runs a `node:https` mTLS handshake and reads the peer certificate on the server:\n\n```js\nimport https from 'node:https';\nimport { execFileSync } from 'node:child_process';\nimport { mkdtempSync, writeFileSync, readFileSync, rmSync } from 'node:fs';\nimport { tmpdir } from 'node:os';\nimport { join } from 'node:path';\n\n// Generate root CA -> intermediate CA -> client leaf and server cert\nconst dir = mkdtempSync(join(tmpdir(), 'mtls-'));\nconst f = (n) => join(dir, n);\nconst openssl = (...a) => execFileSync('openssl', a, { stdio: 'ignore' });\nconst ec = ['-newkey', 'ec', '-pkeyopt', 'ec_paramgen_curve:prime256v1', '-nodes'];\n\nopenssl('req', '-x509', ...ec, '-keyout', f('root.key'), '-out', f('root.crt'),\n  '-days', '2', '-subj', '/CN=Repro Root CA', '-addext', 'basicConstraints=critical,CA:TRUE');\n\nwriteFileSync(f('int.ext'), 'basicConstraints=critical,CA:TRUE,pathlen:0\\nkeyUsage=critical,keyCertSign,cRLSign\\n');\nopenssl('req', ...ec, '-keyout', f('int.key'), '-out', f('int.csr'), '-subj', '/CN=Repro Intermediate CA');\nopenssl('x509', '-req', '-in', f('int.csr'), '-CA', f('root.crt'), '-CAkey', f('root.key'),\n  '-CAcreateserial', '-days', '2', '-extfile', f('int.ext'), '-out', f('int.crt'));\n\nwriteFileSync(f('leaf.ext'), 'basicConstraints=critical,CA:FALSE\\nkeyUsage=critical,digitalSignature\\nextendedKeyUsage=clientAuth\\n');\nopenssl('req', ...ec, '-keyout', f('leaf.key'), '-out', f('leaf.csr'), '-subj', '/CN=Repro Client');\nopenssl('x509', '-req', '-in', f('leaf.csr'), '-CA', f('int.crt'), '-CAkey', f('int.key'),\n  '-CAcreateserial', '-days', '2', '-extfile', f('leaf.ext'), '-out', f('leaf.crt'));\n\nopenssl('req', '-x509', ...ec, '-keyout', f('srv.key'), '-out', f('srv.crt'),\n  '-days', '2', '-subj', '/CN=localhost', '-addext', 'subjectAltName=DNS:localhost');\n\nconst root = readFileSync(f('root.crt'));\nconst clientChain = Buffer.concat([readFileSync(f('leaf.crt')), readFileSync(f('int.crt'))]);\n\nconst server = https.createServer(\n  { key: readFileSync(f('srv.key')), cert: readFileSync(f('srv.crt')), ca: [root],\n    requestCert: true, rejectUnauthorized: false },\n  (req, res) => {\n    const cert = req.socket.getPeerCertificate(true);\n    console.log('node', process.version, '| authorized:', req.socket.authorized,\n                '| issuerCertificate present:', !!cert.issuerCertificate);\n    res.writeHead(200); res.end('x');\n  });\nserver.listen(0, 'localhost', () => {\n  const req = https.request(\n    { hostname: 'localhost', port: server.address().port,\n      key: readFileSync(f('leaf.key')), cert: clientChain, ca: [root], rejectUnauthorized: false },\n    (res) => { res.resume(); res.on('end', () => { server.close(); rmSync(dir, { recursive: true, force: true }); }); });\n  req.end();\n});\n```\n\nCompare output on an affected and an unaffected version:\n\n```\n$ node-v26.7.0 repro.mjs\nnode v26.7.0 | authorized: true | issuerCertificate present: true\n$ node-v26.8.1 repro.mjs\nnode v26.8.1 | authorized: true | issuerCertificate present: false\n```\n\n### How often does it reproduce? Is there a required condition?\n\nEvery time on Node >= 26.8.0. Requires `requestCert: true`, a client certificate signed through at least one intermediate, and reading the chain with `getPeerCertificate(true)` or `getPeerCertificate` with `includeChain`.\n\n### What is the expected behavior? Why is that the expected behavior?\n\n`getPeerCertificate(true)` on the server should return the leaf with an `issuerCertificate` property linking to the intermediate (and so on up the chain), as it did through v26.7.0 and as [documented](https://nodejs.org/api/tls.html#tlssocketgetpeercertificatedetailed): \"If the full certificate chain was requested, each certificate will include an `issuerCertificate` property containing an object representing its issuer's certificate.\"\n\n### What do you see instead?\n\nThe leaf is returned fully populated (subject, issuer, `raw`, fingerprints, etc.) but `issuerCertificate` is `undefined`. `getPeerX509Certificate().issuerCertificate` is also absent.\n\n### Additional information\n\nI bisected nightly builds and `v27.0.0-nightly20260808` (`aed4eaf89d`) is the last one before the break; `v27.0.0-nightly20260809` (`0700e749eb`) is where it breaks. The only tls/crypto commit in that range is c59cd6b04 (#64677), \"tls: fix authorized state on no-cert TLS1.3 client cert resumption\", which added to `onServerSocketSecure()` in `lib/internal/tls/wrap.js`.\n\nCalling `getPeerX509Certificate()` caches the peer certificate as a leaf only, so subsequent `getPeerCertificate(true)` returns the cached leaf only.\n\nThe underlying issue is really a caching interaction that predates #64677, which is that calling `getPeerX509Certificate()` poisons `getPeerCertificate(true)`. It can be reproduced on the unaffected versios by inserting that call before reading the chain, i.e., insert `req.socket.getPeerX509Certificate();` as the first line of the request handler in the repro above. #64677 tripped this by calling `getPeerX509Certificate()` internally.\n\nThere are sort of two issues here AFAICT: the caching interaction where `getPeerX509Certificate()` mutates the chain for a later `getPeerCertificate(true)`, and #64677 using `getPeerX509Certificate()` just to test presence of a peer certificate (instead of a check that does not populate/replace the cached peer certificate).\n\nThis regression affects any server that inspects the client certificate chain on Node >= 26.8.0.","author":{"url":"https://github.com/tgies","@type":"Person","name":"tgies"},"datePublished":"2026-08-27T09:47:45Z","url":"https://github.com/nodejs/node/issues/65579"}