http2/quic: Support of custom certificate verifier, serverCertificateHashes

What is the problem this feature will solve?

I am currently trying to implement http/2 webtransport with native node functions.
Webtransport has (at least on http/3) the feature, that certificates are verified using a hash identifier if their validity is below 14 days.
My objective is to achieve this also for the http/2 implementation. (I believe that similar problems may arrise for http/3 webtransport for the upcoming quic/http/3 infrastructure, although different code is used for quic then for TCP TLS)

What is the feature you are proposing to solve the problem?

So far, I tried to use the checkServerIdentity feature for checking.
However, if the verification fails at
https://github.com/nodejs/node/blob/ab5fa2a2210416b0db0e601620da81ce34adf59a/lib/_tls_wrap.js#L1600C35-L1600C47
checkServerIdentity is never called.
The verification happens inside OpenSSL apparently.
I got a self-signed certificate error in my first attempts, so it did not reach the checkServerIdentity.
I can not supply the certificate as ca, as I do not know it before a connection.
rejectUnauthorized=false is not an option, as it also removes the call to checkServerIdentity:

I see the following options:

1. I have missed something, and there is a workaround, so that patch for node.js is not required (as it would allow usage in older node versions, this is my preferred option).
2. An option for supplying a custom certificate verifier function as a replacement for the OpenSSL version, analog to checkServerIdentity
3. An option to use only checkServerIdentity and no certificate verification with OpenSSL

(If I am not mistaken, this is also missing for the tlscontext.cc in quic).

Of course, whatever option is the best (if any), I would be happy to create a PR.

What alternatives have you considered?

No response

Start by reading the certificate-verification path in lib/_tls_wrap.js around the referenced checkServerIdentity call, then inspect tlscontext.cc for the corresponding QUIC path. Compare the existing OpenSSL verification behavior with the proposed custom verifier and define the API scope, including whether HTTP/2 and QUIC are both covered. Done means the chosen verification behavior is specified and tested for the relevant transport.