-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getPeerCertificate() only works once on the same host #3940
Comments
/cc @nodejs/http |
The session is resumed the next time, so this info is no longer available. It is actually a pretty good question on how it should work. @nodejs/crypto : what are your thoughts on this? Should we store the cert in the session cache? |
If we store the cert, we need to check its revocation at every connection even if it is a short time. |
@shigeki technically, the session should expire if the cert has expired. I mean, if the server has made session timeout way too high, it is its fault, and not node.js. I'm definitely +1 for an option to disable it, however I think that the particular request code should not depend on agent configuration. @f0zi could using |
@indutny Not really, if I don't see the cert I have to abort the connection. Since I'm using this from inside node-fetch I can't easily restart the request internally (I tried Note that I would be ok with reusing the request as long as it's the same domain (as sent with SNI). If it is talking to the same host but for a different domain as requested it would have to request the right cert from the host. Would it be possible to limit a request to reusing a session to the domain indicated by SNI or trigger a renegotiation otherwise? |
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: nodejs#3940
@f0zi SNI should be indeed accounting when doing https requests. Filed a PR to fix this issue: #4389, thanks for pointing out! Regarding the Cheers! |
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: #3940 PR-URL: #4389 Reviewed-By: Ben Noordhuis <[email protected]>
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: nodejs#3940 PR-URL: nodejs#4389 Reviewed-By: Ben Noordhuis <[email protected]>
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: #3940 PR-URL: #4389 Reviewed-By: Ben Noordhuis <[email protected]>
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: #3940 PR-URL: #4389 Reviewed-By: Ben Noordhuis <[email protected]>
https requests with different SNI values should not be sent over the same connection, even if the `host` is the same. Server may want to present different certificate or route the incoming TLS connection differently, depending on the received servername extension. Fix: nodejs#3940 PR-URL: nodejs#4389 Reviewed-By: Ben Noordhuis <[email protected]>
So I've been struggling with this as well and here is how I get a fresh cert and fingerprint every time.
|
Requesting from the same host twice using https will only return the certificate on the first connection.
I would expect to get back the cert every time even if the connection is reused.
I'm caching it now but it's a bad workaround as other code could be using
https.request
to connect to the same host without using the cache which means that my code will never see the cert.Also caching the cert means I'm relying on the assumption that the fact that I did not get a cert this time means the cert in my cache still applies and is valid.
The text was updated successfully, but these errors were encountered: