http2: Support of custom certificate verifier

[martenrichter]

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

[martenrichter]

Well no feedback so far...., as I said, I may write a PR for this, if I know it has a chance to land in node.js...

[martenrichter]

Ok, I have now implemented a workaround, doing verification after connection:
fails-components/webtransport@fb9b7dc
I do not like this, but it will work for now.

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[martenrichter]

Well no feedback so far...., I just post something to make the bot happy.

[github-actions]

There has been no activity on this feature request for 5 months. To help maintain relevant open issues, please add the never-stale Mark issue so that it is never considered stale label or close this issue if it should be closed. If not, the issue will be automatically closed 6 months after the last non-automated comment.
For more information on how the project manages feature requests, please consult the feature request management document.

[martenrichter]

Ping to keep it open.