tls: fix SNICallback certificate selection

[mcollina]

Fixes #54235

[nodejs-github-bot]

Review requested:

• @nodejs/crypto

[mcollina]

I feel this might be semver-major

[codecov]

Codecov Report

❌ Patch coverage is 50.00000% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 90.12%. Comparing base (efc0a14) to head (5544c13).
⚠️ Report is 16 commits behind head on main.

Files with missing lines	Patch %	Lines
src/crypto/crypto_tls.cc	50.00%	0 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #64700      +/-   ##
==========================================
+ Coverage   90.11%   90.12%   +0.01%     
==========================================
  Files         741      741              
  Lines      242196   242247      +51     
  Branches    45606    45613       +7     
==========================================
+ Hits       218246   218335      +89     
+ Misses      15438    15407      -31     
+ Partials     8512     8505       -7     

Files with missing lines	Coverage Δ
src/crypto/crypto_tls.cc	78.32% <50.00%> (+0.01%)	⬆️

... and 49 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.

[lemire]

LGTM

[pimterry]

I think that this is a bigger change than it needs to be to fix the bug, in a way that will break things. It doesn't just replace the cert configuration: it swaps out the entire context, which has all the other TLS configuration and runtime internals attached to it.

This means it pulls in other configuration from the context returned by the SNI callback provided: e.g. it replaces at least ciphers, sigalgs, dhparam with the SNI result value.

Given the normal patterns for this today (nothing but certs configured on the SNI result value, because all other config does nothing) in practice that means for existing code this silently resets every TLS handshake to our default configuration, dropping most server/client custom TLS options you set.

It also drops things we internally store on the context - I set claude on it, it thinks this'd break at least keylog, OCSP stapling, ALPNProtocols/ALPNCallback (on TLS 1.2) and all session resumption.

Honestly if we were designing from scratch I think this might be the right shape - it gives you a hook to set per-SNI TLS context configuration which is neat - but it would be a very high-risk breaking change to existing code today. If we want that replace-context behaviour, I think we need to make a new option name for it to make it opt-in. Without that, replacing the context silently wipes custom TLS configurations (not to mention breaking the features above).

We don't need to do this to fix the bug though. I think we can just wipe the cert config of the existing context with SSL_certs_clear, and then add the new certs as before with no risk of old certs applying. We don't need to replace the whole context.