tls: normalize the hostname for server identity checks - #42977

…host parse (#43040)

### Problem
- Since #42977, `tls.checkServerIdentity("evil.test/.example.com",
cert)` accepts a certificate for `evil.test`. So do `tls.connect` and
`https.request`. Before: `ERR_TLS_CERT_ALTNAME_INVALID`.
- `checkServerIdentity` (`src/js/node/tls.ts:458`) matches on
`url.domainToASCII(hostname)`, a URL host parse (`parseDomainAsHost`,
`src/jsc/bindings/NodeURL.cpp:121`). It cuts the name at `/`, `?`, `#`
and `\`, drops tab, CR and LF, and decodes `%xx`.
- The native matcher (`check_x509_server_identity`,
`src/boringssl/lib.rs:446`) runs the same parse for a non-ASCII host.
`fetch` and `Bun.connect` accept `ｅvil.test/.example.com` (U+FF45). They
also accept `evil.test\0.example.com`: `tls.serverName` is a C string
(`src/runtime/socket/SSLConfig.rs:165`).

### Fix
- Both matchers map a non-ASCII host with UTS #46 alone (`icuToASCII`),
which never cuts a name. An ASCII host is matched as typed, as in Bun
1.4.2.
- `a b.example.com`, `[email protected]` and `db.1` go from rejected
back to accepted in `tls.checkServerIdentity`. #42977 rejected them to
stay bug for bug with Node
([reply](#42977 (comment))).
That parity is dropped: in Bun the same call is the bypass.
- A NUL in `tls.serverName` now throws in the native clients. `node:tls`
does not change: it fails with `ERR_TLS_CERT_ALTNAME_INVALID`, as in
Node.
- Verified: `test/js/web/fetch/fetch.tls.wildcard.test.ts` (44 of 144
fail on main). Self-reviewed: 8 concerns raised, 6 addressed, 2 deferred
(Notes).

### Background
- `checkServerIdentity` compares the host with each certificate DNS
name, label by label. A left-most `*` is one label.
- UTS #46 (IDNA) maps a Unicode domain name to ASCII, and three
ideographic full stops to ".". It knows no URL syntax.
- `url.domainToASCII` is a WHATWG URL host parse. The parse includes
that mapping.
- Bun has two matchers: the JS one in `node:tls`, and a Rust port for
every native TLS client.

<details><summary>Notes</summary>

**Repro** (no network)

```js
const tls = require("tls");
const evil = { subjectaltname: "DNS:evil.test", subject: {} };
const wild = { subjectaltname: "DNS:*.example.com", subject: {} };
for (const [host, cert] of [
  ["evil.test/.example.com", evil], ["evil.test#.example.com", evil], ["evil.test\\.example.com", evil],
  ["evil.test\r\n", evil], ["e%76il.test", evil],
  ["foo.example.com/x.evil.test", wild], ["foo%2eexample.com", wild],
  ["foo\u3002bar.example.com", wild],
])
  console.log(JSON.stringify(host).padEnd(34), tls.checkServerIdentity(host, cert) ? "rejected" : "ACCEPTED");
```

| build | rows 1 to 7 | row 8 (U+3002) |
| --- | --- | --- |
| Bun canary c6b7fcb (before #42977), Node v26.3.0 | rejected |
ACCEPTED |
| main 630e921 | ACCEPTED | rejected |
| this branch | rejected | rejected |

**End to end.** The server has one certificate, `DNS:evil.test`. The
client dials 127.0.0.1 with the name as `servername` / `tls.serverName`.
Rejected means `ERR_TLS_CERT_ALTNAME_INVALID`.

| name | entry point | canary c6b7fcb | main | this branch |
| --- | --- | --- | --- | --- |
| `evil.test/.example.com` (also `#`, `?`, `\`, CR LF, `e%76il.test`) |
`tls.connect`, `https.request` | rejected | authorized | rejected |
| the same | `fetch`, `Bun.connect` | rejected | rejected | rejected |
| `ｅvil.test/.example.com` (also `#`, `?`, `\`, CR LF, `ｅ%76il.test`) |
all four | rejected | authorized | rejected |
| `evil.test\0.example.com` | `tls.connect`, `https.request` | rejected
| rejected | rejected |
| the same | `fetch`, `Bun.connect` | authorized | authorized | throws |
| `evil.test` | all four | authorized | authorized | authorized |
| `ｅvil.test` | all four | rejected | authorized | authorized |

**Reach.** Only a raw `host` or `servername` string gets there, and no
resolver resolves such a name. It takes an application that passes
unvalidated input as `servername` (or uses a custom `lookup`, or a proxy
that connects first) and validates the raw string, for example with a
suffix allow-list. `evil.test/.example.com` ends with `.example.com`. No
release has the `domainToASCII` part. The NUL part is older (canary
c6b7fcb has it).

**Why the plain mapping**
- The check must see the label structure that a resolver looks up. A
resolver that applies IDNA maps the three full stops to ".". No resolver
cuts a name at "/" or decodes "%xx".
- Node's resolver path uses the plain mapping, `ada::idna::to_ascii`, in
`cares_wrap.cc`. #35590 does the same for Bun's `node:dns` with
`icuToASCII`.
- `icuToASCII` over every code point `c` in `"evil.test" + c +
".example.com"`: 156,412 inputs convert and 955,524 do not. Each
converted output is ASCII and still ends with `.example.com`. Only
U+3002, U+FF0E and U+FF61 change the label count. 294 code points are
dropped (for example U+00AD), which an IDNA resolver does too.
- A host that does not convert matches nothing, as before.

**ASCII hosts**
- No ASCII code point maps to "." and no resolver maps an ASCII name, so
the label split is correct as typed. #42977 gave that reason for the
native matcher, and it holds for the JS matcher too.
- For every ASCII row in the tests, this branch gives the verdict,
`reason` and `host` of Node v26.3.0 and of Bun before #42977. For the
rows of #42977 it gives the Node v26.8.2 result, with the one documented
exception (an empty first label).
- `db.1` is a real case: a certificate for `db.1` did not match its own
host on main, because a URL host with a numeric last label must parse as
IPv4.

**The two matchers.** They share the rule for the IDNA step. A
differential run of 3,154 host and certificate pairs through
`tls.checkServerIdentity` and `fetch` (`tls.serverName`): 202
differences on main, 1 on this branch. The one left is the empty
`serverName`, which means "not set", so `fetch` checks the URL host.
What still differs by entry point:
- `socket.setServername()` and `server.addContext()` cut the SNI name at
a NUL on the wire. #37013 covers it, with the rest of the NUL class
(hostnames, IP strings, QUIC SNI).
- `X509Certificate#checkHost`, the HTTP/3 client and `node:quic` use
OpenSSL rules, as in Node.

**NUL in `tls.serverName`.** `SSLConfig` keeps the name as a C string,
so SNI and the native check saw `evil.test` for
`evil.test\0.example.com`. This is the same class as the URL cut, so the
guard is here and not left to #37013 (open since 2026-08, conflicts with
main). The guard and the message are the ones #37013 has for this field.
`Bun.SQL` and `RedisClient` reject with the same error. `node:tls` never
had the hole, because `checkServerIdentity` gets the whole JS string. So
`node:tls` hands the native layer the name up to the NUL (`sniName` in
`tls.ts`), which is what SNI carried before. `tls.connect` and
`https.request`, with or without a `secureContext`, still emit `'error'`
with `ERR_TLS_CERT_ALTNAME_INVALID`, as Bun 1.4.2 and Node v26.8.2 do.
Without that step the guard made them throw, and with a `secureContext`
the throw was uncaught.

**Review.** The other C strings in `SSLConfig::from_generated`
(`ciphers`, `sigalgs`, the PEM strings, the file paths) are also cut at
a NUL. That is older than this PR, Node v26.8.2 does the same for its
options, and none of them takes part in the name check. #37005 covers
the file paths.

**Self-review.** Addressed: the NUL guard, the plain statement of the
rows that go back to accepted, the link to the #42977 reply, the reason
parity is dropped, the narrower claim about the two matchers, and the
list of what still differs. Left for a follow-up, because they are
refactors and not part of this bug: one shared matcher (the JS DNS
branch calls the Rust one), and a test-only binding that compares the
two matchers without a TLS server.

**Related, not in this PR**
- `runUIDNA` aborts on an input of about 2^30 characters.
`tls.checkServerIdentity` could already reach it through
`domainToASCII`. #42856 covers it.

**Tests**
- `fetch.tls.wildcard.test.ts`: `tls.connect` and `Bun.connect` end to
end for a URL path in the name (ASCII and with U+FF46), 20 new rows in
the `checkServerIdentity == fetch` table, 18 new rows for
`tls.checkServerIdentity` with the error text, and 3 tests for a NUL
through `fetch`, `Bun.connect` and `tls.connect` (with and without a
`secureContext`). main 630e921: 100 pass, 44 fail. This branch: 144
pass.
- `test/js/node/test/parallel/test-tls-check-server-identity.js`
(byte-identical to Node v26.8.2) passes.
- Also ran with the debug build:
`node-tls-connect-hostname-verification.test.ts`,
`node-https-checkServerIdentity.test.ts`, `fetch.tls.test.ts`,
`fetch.tls.ipv6.test.ts`, `fetch-session.test.ts`,
`valkey-tls-verify.test.ts`, `node-tls-cert.test.ts`,
`node-tls-connect.test.ts`, `node-tls-context.test.ts`,
`node-tls-server.test.ts`, `bun-serve-ssl.test.ts`,
`tls-keepalive.test.ts`, `test/js/node/url/`,
`test/js/bun/net/socket.test.ts`, `test/internal/source-lints/`, and the
247 vendored `test-tls-*`, `test-https-*`, `test-x509-*` and `domainTo*`
files.
- Four failures, none in this area. The `URL.canParse` 1e5-iteration
loop passes the 5 s timeout in the debug build. `socket.test.ts` "should
not call drain before handshake" needs `www.example.com`, and this
machine has no DNS. `node-tls-server.test.ts` "SNICallback runs even
when..." gets `ECONNREFUSED` on `localhost` here, on the release canary
too. `test-https-timeout.js` hangs in the debug build and passes in 76
ms on the release canary.

</details>

<!-- robobun:evidence:begin -->

---

**[human-review]** gate passed · iteration 0 · 5 files touched

<details><summary>fails on main (without fix)</summary>

```console
ASAN without fix: 44 FAILED
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/web/fetch/fetch.tls.wildcard.test.ts
bun test v1.4.3 (c6b7fcb)

test/js/web/fetch/fetch.tls.wildcard.test.ts:
(pass) TLS wildcard hostname verification > should reject multi-label wildcard match (sub.foo.example.com vs *.example.com) [700.16ms]
(pass) TLS wildcard hostname verification > should accept valid single-label wildcard match (foo.example.com vs *.example.com) [430.74ms]
(pass) TLS wildcard hostname verification > should reject bare domain for wildcard cert (example.com vs *.example.com) [424.22ms]
(pass) TLS wildcard hostname verification > should accept exact match for wildcard labels (bar.example.com vs *.example.com) [445.13ms]
(pass) TLS wildcard hostname verification > should reject deeply nested subdomain (a.b.c.example.com vs *.example.com) [441.91ms]
(pass) TLS wildcard hostname verification > should accept case-insensitive wildcard match (FOO.EXAMPLE.COM vs *.example.com) [304.88ms]
(pass) TLS wildcard hostname verification > should accept mixed-case wildcard match (FoO.ExAmPlE.cOm vs *.example.com) [288.85m
... (truncated)

release without fix: 26 FAILED
bun test v1.4.3-canary.1 (c6b7fcb)

test/js/web/fetch/fetch.tls.wildcard.test.ts:
(pass) TLS certificate name matching: fetch() / checkServerIdentity / checkHost agree > checkServerIdentity == fetch > "foo.wild.test" [13.80ms]
(pass) TLS wildcard hostname verification > should reject multi-label wildcard match (sub.foo.example.com vs *.example.com) [45.17ms]
(pass) TLS wildcard hostname verification > should accept valid single-label wildcard match (foo.example.com vs *.example.com) [36.16ms]
(pass) TLS wildcard hostname verification > should reject bare domain for wildcard cert (example.com vs *.example.com) [34.63ms]
(pass) TLS wildcard hostname verification > should accept exact match for wildcard labels (bar.example.com vs *.example.com) [34.41ms]
(pass) TLS wildcard hostname verification > should reject deeply nested subdomain (a.b.c.example.com vs *.example.com) [33.07ms]
375 |           reject(new Error("closed before the handshake callback"));
376 |         },
377 |       },
378 |     });
379 |     try {
380 |       expect(await promise).toEqual({
                                  ^
error: expect(received).toEqual(expected)

  {
-   "authorized": false,
- 
... (truncated)
```

</details>

<details><summary>passes on PR (with fix)</summary>

```console
ASAN with fix: all passed
$ BUN_DEBUG_QUIET_LOGS=1 bun scripts/build.ts --profile=debug --quiet test "--reporter=junit" "--reporter-outfile=/tmp/pr_gate.xml" test/js/web/fetch/fetch.tls.wildcard.test.ts
bun test v1.4.3 (c6b7fcb)

test/js/web/fetch/fetch.tls.wildcard.test.ts:
(pass) TLS wildcard hostname verification > should reject multi-label wildcard match (sub.foo.example.com vs *.example.com) [733.51ms]
(pass) TLS wildcard hostname verification > should accept valid single-label wildcard match (foo.example.com vs *.example.com) [463.92ms]
(pass) TLS wildcard hostname verification > should reject bare domain for wildcard cert (example.com vs *.example.com) [454.31ms]
(pass) TLS wildcard hostname verification > should accept exact match for wildcard labels (bar.example.com vs *.example.com) [500.63ms]
(pass) TLS wildcard hostname verification > should reject deeply nested subdomain (a.b.c.example.com vs *.example.com) [495.61ms]
(pass) TLS wildcard hostname verification > should accept case-insensitive wildcard match (FOO.EXAMPLE.COM vs *.example.com) [346.36ms]
(pass) TLS wildcard hostname verification > should accept mixed-case wildcard match (FoO.ExAmPlE.cOm vs *.example.com) [338.68m
... (truncated)

release with fix: all passed
$ bun scripts/build.ts --profile=release
[configured] bun-profile → bun (stripped)
  target       linux-x64-gnu
  build type   Release
  build dir    ./build/release
  revision     091810f
  features     lto, baseline

23 deps, 131 codegen, 1176 objects in 708ms

ninja: Entering directory `/workspace/bun/build/release'
[1/1250] install /workspace/bun
bun install v1.4.3-canary.1 (c6b7fcb)

Checked 22 installs across 61 packages (no changes) [16.00ms]
[2/1250] install /workspace/bun/packages/bun-error
bun install v1.4.3-canary.1 (c6b7fcb)

Checked 1 install across 2 packages (no changes) [1.00ms]
[3/1250] gen ErrorCode+*.h
[4/1250] install /workspace/bun/src/node-fallbacks
bun install v1.4.3-canary.1 (c6b7fcb)

Checked 111 installs across 104 packages (no changes) [16.00ms]
[5/1250] gen node-fallbacks/react-refresh.js
Bundled 1 module in 12ms

  react-refresh.js  4.81 KB  (entry point)

[6/1250] gen bindgenv2
[7/1250] fetch zlib
[zlib] up to date
[8/1250] fetch tinycc
[tinycc] up to date
[9/1249] gen .bind.ts → GeneratedBindings.cpp
[10/1249] gen bake.{client,server,error}.js
-> bake.client.js, bake.server.js, bake.error.js
[11/1249] fetch libjpeg-turbo
[
... (truncated)
```

</details>

<details><summary>diff hotspot</summary>

```
src/boringssl/lib.rs                         |   9 +-
 src/js/node/tls.ts                           |  12 +-
 src/jsc/bindings/NodeURL.cpp                 |  12 +-
 src/runtime/socket/SSLConfig.rs              |   9 +-
 test/js/web/fetch/fetch.tls.wildcard.test.ts | 158 ++++++++++++++++++++++-----
 5 files changed, 160 insertions(+), 40 deletions(-)
```

</details>

**gate history** · 1 passed · 0 rejected · iteration 0

<details><summary>evidence per changed file</summary>

```
file                                          reads  edits  tests
src/boringssl/lib.rs                              1      1     15
src/js/node/tls.ts                                3      4     15
src/jsc/bindings/NodeURL.cpp                      1      1     15
src/runtime/socket/SSLConfig.rs                   1      1     16
test/js/web/fetch/fetch.tls.wildcard.test.ts      4      9     15
```

</details>

<!-- robobun:evidence:end -->

…#43873)

### Problem
- `tls.checkServerIdentity("localhost/.evil.test", cert)` accepts a
certificate for `*.evil.test`, and so do `tls.connect`, `fetch` and
`Bun.connect`. An application that validates the name with a URL parser
sees `localhost`.
- Both matchers compare an ASCII host as typed
(`src/js/node/tls.ts:488`, `src/boringssl/lib.rs:446`), so `*` covers
any first label, also `localhost/`. Every Bun release and Node v26.3.0
do this.

### Fix
- In both matchers, a DNS host with a character outside letters, digits,
`-`, `_` and `.` matches nothing. The rule runs after the IDNA step. It
supersedes "an ASCII host is matched as typed" from #43040.
- IP hosts: the native matcher takes only the strict form of `net.isIP`
(`127.1` matched the IP SAN 127.1.0.0). `tls.checkServerIdentity` no
longer matches `::1%lo` against a malformed IP SAN.
- Verified: `test/js/web/fetch/fetch.tls.wildcard.test.ts` (35 of 183
fail on main, with a sweep of the 62 excluded ASCII bytes).
Self-reviewed: 13 concerns, 4 changes made, 3 follow-ups (Notes).

### Background
- Two matchers share Node's rules: `checkServerIdentity` in `node:tls`,
and a Rust port for the native TLS clients.
- Considered: limit only what `*` covers (OpenSSL's rule). Exact matches
of such names stay. A revert of #43040 opens `evil.test/.example.com`
again.

### Downsides
- Node v26.8.2 rejects 43 of the 62 bytes (`/`, `?`, `#`, space, `@`).
Only Bun rejects the other 19, a literal `*` host, and an exact name
like `exact!name.test` against the same SAN. A test that expects Node's
result fails.
- Cost: 425 bytes less text in the release binary.
`tls.checkServerIdentity` for a plain hostname: 2,476 ns per call, main
2,494, noise floor 0.9%. Native: one more host scan per handshake.

<details><summary>Notes</summary>

**Repro** (no network)

```js
const tls = require("tls");
const cert = { subjectaltname: "DNS:*.evil.test", subject: {} };
for (const host of ["localhost/.evil.test", "localhost?.evil.test", "localhost#.evil.test", "localhost\\.evil.test", "db:5432/.evil.test"])
  console.log(JSON.stringify(host).padEnd(26), tls.checkServerIdentity(host, cert) ? "rejected" : "ACCEPTED");
```

| build | result |
| --- | --- |
| Bun 1.4.2, Node v26.3.0 | ACCEPTED |
| main with #42977 and without #43040 (6d504dd) | rejected |
| main 2838e1b | ACCEPTED |
| this branch, Node v26.8.2 | rejected |

**End to end.** The server has one certificate, `DNS:*.evil.test`. The
client dials 127.0.0.1 with `localhost/.evil.test` as `servername` /
`tls.serverName`.

| entry point | Bun 1.4.2 | main 6d504dd (before #43040) | main with
#43040 | this branch |
| --- | --- | --- | --- | --- |
| `tls.connect` | authorized | rejected | authorized | rejected |
| `fetch` | authorized | authorized | authorized | rejected |

The native matcher never had the URL host parse for an ASCII name, so
`fetch` and `Bun.connect` accept the name in every build before this
one.

**Reach.** Only a raw `host` or `servername` string gets there. It takes
an application that validates the name with a URL parser (it sees
`localhost`, or another single-label name that it trusts) and passes the
raw string as `servername`, and an attacker who receives the connection
with a `*.evil.test` certificate. It is the mirror image of the case
that #43040 closed (`evil.test/.example.com` against a raw-string suffix
check). One reading of the name is not enough: a name with two readings
must not match.

**The rule**
- The set is letters, digits, `-`, `_` and `.`. An underscore is in it
because such names exist (`foo_bar.example.com` under `*.example.com`
keeps working). `db.1`, `xn--a.example.com`, a trailing dot and an IP
literal keep working. A literal `*` in the host no longer matches a
wildcard.
- It runs on the name the matcher compares: as typed for an ASCII host,
and the UTS #46 form for a host with a non-ASCII code point. So a mapped
delimiter (`localhost／.evil.test`) is rejected, and `bücher.example.com`
still matches `xn--bcher-kva.example.com`.
- JS: an empty label list never matches in `check()`. Rust:
`host_is_dns_name` gates the SAN loop and the CN fallback in
`check_x509_server_identity`, the one function every native client
calls. `X509Certificate#checkHost` keeps OpenSSL's rules, where `*`
already covers only letters, digits and `-`.
- The error text does not change: `Host: localhost/.evil.test. is not in
the cert's altnames: DNS:*.evil.test`.

**IP shorthand.** `check_x509_server_identity` asked `ares_inet_pton`
whether the host is an IP address. That function is `inet_net_pton`
underneath: it reads `127.1` as 127.1.0.0 and `10` as 10.0.0.0, and it
takes hex, zero-padded octets and a trailing `/bits`. A resolver reads
`127.1` as 127.0.0.1, so such a name has two readings too. With a
certificate that has the IP SANs 127.0.0.1, 127.1.0.0, 10.0.0.0, 1.2.3.4
and 1.2.3.0, `fetch` accepted `127.1`, `10`, `0x7f000001`,
`127.000.000.001`, `1.2.3`, `1.2.3.4/8` and `127.0.0.1/32` on Bun 1.4.2
and on main, and `tls.checkServerIdentity` rejected each of them. The
native matcher now uses `ip_address::parse_strict`, and both reject
them. `net.isIP` was already strict.

**Zone ids.** `net.isIP` takes an IPv6 address with a zone (`::1%lo`),
and `canonicalizeIP()` returns `undefined` for it. It also returns
`undefined` for a malformed iPAddress SAN, which the certificate prints
as `IP Address:<invalid>`. `tls.checkServerIdentity` then found
`undefined` in the list and accepted: with a certificate that has a
5-byte iPAddress SAN, Bun 1.4.2 and main accept `::1%lo` and
`fe80::1%eth0`, and Node and the native matcher reject them. The IP
branch now needs a canonical form of the host. Both matchers reject a
host with a zone, as before for a well-formed SAN. Node strips the zone
and accepts `::1%lo` for the IP SAN `::1`. That is a follow-up, because
both matchers need it.

**Node and prior art.** Of the 62 ASCII bytes outside the set (NUL
aside), Node v26.3.0 accepts all 62 in the label under `*`, as Bun 1.4.2
does. Node v26.8.2 rejects 43, because its `url.domainToASCII` step
fails on them. It accepts the other 19: tab, CR and LF, which the URL
parse drops, and ``!"$&'()*+,;=`{}~``, which are URL host characters. Of
the 21 hosts that the tests pin as rejected, v26.8.2 rejects 18 with the
same code, reason and host. It accepts `*.wild.test`, `*.example.com`
and `exact!name.test`, and the tests mark those rows as Bun only. rustls
and mozilla::pkix (Firefox) refuse a reference name that is not a DNS
name in the same way, and both allow the underscore. Go limits wildcard
matches to valid hostnames and keeps an exact match.

**Differential run.** 3,682 pairs of a host and a certificate through
`tls.checkServerIdentity` and `fetch` (`tls.serverName`). main: 656
accepted, of which 401 have an ASCII character outside the set (for
example `foo\r.wild.test` under `*.wild.test`). This branch: 178
accepted, 0 with such a character. The one difference between the
matchers in that run is the empty `serverName`, which means "not set".
The run is a script outside the tree. In the tree, the test file now
sweeps all 62 bytes through both matchers on one server, and a grid of
IP shorthand, zone ids and a malformed iPAddress SAN.

**Cost.** Release builds of main 2838e1b with and without this diff.
`size`: text 80,659,886 to 80,659,461 bytes (-425, the strict parse
replaces two `ares_inet_pton` calls with their 512-byte buffers), data
and bss unchanged, file 80,827,936 bytes in both. The first commit alone
was +87 bytes. CPU per call from `process.cpuUsage()` for
`tls.checkServerIdentity("foo.example.com", cert)`, 2e6 calls, 11
interleaved rounds of main, this diff, main again: 2,494, 2,476 and
2,516 ns. The JS matcher adds one regex test per DNS-name check. The
native matcher adds one pass over the host bytes per handshake, and it
parses the host once with `core::net` where it called `ares_inet_pton`
up to twice. `perf`, `valgrind` and `bloaty` are not on this machine, so
there is no instruction count.

**Self-review.** It asked for four changes, and all are in: the guard in
the JS IP branch, test comments that name the rows only Bun rejects,
this description (it supersedes the rule of #43040 and splits the
rejected names by Node's verdict), and the in-tree sweep in place of the
script. Follow-ups, not in this PR: `tls.checkServerIdentity` can call
the Rust matcher, so that one implementation is left.
`bun_core::ip_address::is_ip_address` still uses `ares_inet_pton` at its
other call sites, which only decide whether to send SNI. `bun_boringssl`
is not in the crates that CI runs under Miri.

**Tests**
- `fetch.tls.wildcard.test.ts`: `tls.connect` and `Bun.connect` end to
end for `localhost/.example.com` and the U+FF0F form, 12 rows in the
`checkServerIdentity == fetch` table (9 rejected, and `foo_bar`,
`foo-bar`, `xn--a` accepted), and 13 rows for `tls.checkServerIdentity`
with the error text (SAN, CN fallback, an exact odd name, a literal `*`,
and `foo_bar` and a trailing dot accepted). The rows for `a b` and
`user@foo` from #43040 now expect a rejection. Three rows for the native
CN fallback (a certificate with the CN `*.cn.a.test` and no SAN, one of
them `localhost/.cn.a.test` through `fetch`), and 8 rows for IP
shorthand through both matchers. One test sweeps the 62 bytes through
both matchers, and 3 rows cover zone ids with a malformed iPAddress SAN.
main 8d36bff: 148 pass, 35 fail. This branch: 183 pass.
- Also ran with the debug build: `test-tls-check-server-identity.js`,
`node-tls-connect-hostname-verification.test.ts`,
`node-https-checkServerIdentity.test.ts`, `fetch.tls.test.ts`,
`fetch.tls.ipv6.test.ts`, `valkey-tls-verify.test.ts`,
`node-tls-cert.test.ts`, `node-tls-connect.test.ts`, `tls-sql.test.ts`.
All pass.

</details>

---------

Co-authored-by: Jarred Sumner <[email protected]>