Bug: tls.checkServerIdentity rejecting valid IPv6 hostnames in bracket

[Abioy]

What version of Bun is running?

1.3.14

What platform is your computer?

linux x64

What steps can reproduce the bug?

start a https server with:

1. ipv6 as hostname
2. self-signed certificate
3. ipv6 in SAN

run the following script with NODE_EXTRA_CA_CERTS=/path/to/ca.crt bun run xxx.mjs

import { checkServerIdentity } from 'node:tls'
import { isIP } from 'node:net'
process.env.BUN_CONFIG_VERBOSE_FETCH = "true";

// replace the host part with the real ipv6
await fetch('https://[ff:ff:ff:ff:ff:ff:ff:ff]:8088/v1', {
  verbose: true,
  tls: {
    checkServerIdentity: (hostname, cert) => {
      console.log(hostname);
      return checkServerIdentity(hostname, cert);
    },
  },
});

What is the expected behavior?

fetch return normally

What do you see instead?

ERR_TLS_CERT_ALTNAME_INVALID with reason: "Host: [ff:ff:ff:ff:ff:ff:ff:ff]. is not in the cert's altnames: IP Address:FF:FF:FF:FF:FF:FF:FF:FF",

Additional information

The reason is tls.checkServerIdentity did not work well tieh ipv6 hostname in bracket. I fix it and make a PR here: #30662

[robobun]

✅ Reproduced — the URL parser keeps [/] on IPv6 hostnames, so both the native cert check (is_ip_address("[::1]") → false, wrong branch) and your tls.checkServerIdentity callback (receives "[::1]", net.isIP rejects it → CN fallthrough → ERR_TLS_CERT_ALTNAME_INVALID) break. Node strips brackets in urlToHttpOptions before either path runs. Fix mirrors that at the get_tls_hostname chokepoint so every TLS consumer sees the bare "::1".

Fix in PR → #30674