fix(proxy-support): update proxy-support to latest version that works around erraneous expired certs in system CA - #2173

@gribnoysup Do you know if the issue still occurs with the OpenSSL X509_V_FLAG_PARTIAL_CHAIN flag set? The plan here was to skip the X.509 certificate parsing in devtools-shared once that was available to us in mongosh (which it now is) because of the quite significant startup perf overhead. If we can't avoid this problem through other means than sorting the certificates by expiration date, that might be quite a problem for us.

@addaleax is there a way to see which flags are applied when I'm using openssl cli? I didn't check for this flag explicitly because the issue seemed different (issuer is in the CA, not missing, but expired), but I can tell you that openssl connected with the CA list provided while Node.js TLS didn't, but I don't know if this is just something that was happening just because this option was enabled by default or not

This ticket certainly makes it look like the flag is NOT enabled by default openssl/openssl#7871

@lerouxb Yes, hence the PR to Node.js to add that flag: nodejs/node#54790

@gribnoysup If you didn't set that flag manually (-partial_chain) when using the CLI, I think it's safe to say that it's not set.

but I can tell you that openssl connected with the CA list provided while TLS didn't

Yeah, that's ... odd. As far as I could tell in the original investigation here, it's unfortunately not fully deterministic which certificates in the CA list OpenSSL ends up using. I'll try to see if I can reproduce the issue with expired certs using only the CLI and then see if that tells us something.

Thank you! I definitely might've done something wrong when testing, I'm very unfamiliar with openssl cli so had to google around a lot, so intereseted to learn how it goes for you