You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the the certificate is checked against host/ip, even if sendname is set. That means, that the Client asks for a Certificate for domain A but then checks it against the Domain/Address B, which means it is likely to fail if it isn't a cert that is valid for two domains/ip addresses.
This might be mandated by the spec (I don't know all of the HTTP/TLS/Whatever RFCs/Specifications), however it seems counter intuitive.
The text was updated successfully, but these errors were encountered:
Yes. I do use this library every now and then to debug TLS issues for my webservers, but since I have more than one (even on one domain) I like to specify the IP address explicitly, to select which of the Servers I hit (to find out which server is broken). I have until now used a slightly modified version of this library (that sets the openssl params to verify sendname, if sendname is set), which worked like a charm (and is only a 4 line + indenting change), however I though that upstream might benefit as well. If you are interested, I can push my changes into a repo and open a PR, but it was fairly quickly thrown together.
Currently the the certificate is checked against host/ip, even if sendname is set. That means, that the Client asks for a Certificate for domain A but then checks it against the Domain/Address B, which means it is likely to fail if it isn't a cert that is valid for two domains/ip addresses.
This might be mandated by the spec (I don't know all of the HTTP/TLS/Whatever RFCs/Specifications), however it seems counter intuitive.
The text was updated successfully, but these errors were encountered: