GeezerVison

For reference, this PR was generated by https://github.com/nodejs/node/actions/runs/6655826163/job/18086969161 (we should get the workflow to add this link to the PR).

CI: https://ci.nodejs.org/job/node-test-pull-request/55256/

I've canceled that run as it was started too early -- some of the platforms were only building the first commit (and the ones started later both commits).

We'll probably need #50395 to land first for the tests to pass on this version of OpenSSL.

I've rebased this PR to pick up #50395 so the GitHub action runs can pass.

CI: https://ci.nodejs.org/job/node-test-pull-request/55275/

CI: https://ci.nodejs.org/job/node-test-pull-request/55277/

CI: https://ci.nodejs.org/job/node-test-pull-request/55278/

Landed in d1592bd...116b28c

@richardlau @jasnell @RafaelGSS It seems reasonable that this upgrade should also be backported to 18.x since it is security related (albeit low, as already mentioned on the node.js blog post) so that it's in place for the next release cycle.

What's the process to run the openssl updater against older branches, or would it make sense to just do a manual cherry-pick of this commit to the 18.x branch? I see the lts-watch-v18.x label, but I'm not entirely sure what that does.

edit: I seem to have jumped the gun a bit before reading the backporting docs, so I found that the label does in fact mean that the releaser will have an eye on this PR to backport to 18.x when the time is right.

When creating the v18 proposal it should be cherry-picked.