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

Beginne damit, den Pfad zur Zertifikatsüberprüfung in lib/_tls_wrap.js rund um den referenzierten checkServerIdentity-Aufruf zu lesen, und untersuche dann tlscontext.cc auf den entsprechenden QUIC-Pfad. Vergleiche das bestehende OpenSSL-Überprüfungsverhalten mit dem vorgeschlagenen benutzerdefinierten Verifizierer und lege den Umfang der API fest, einschließlich der Frage, ob HTTP/2 und QUIC beide abgedeckt sind. Erledigt bedeutet, dass das gewählte Überprüfungsverhalten für den relevanten Transport spezifiziert und getestet ist.