-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Fix leaf client connection failing in OCSP setups #3964
Conversation
Signed-off-by: Waldemar Quevedo <wally@nats.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So in discussion, the core problem here is that I made a mistake in the original specification for OCSP support, in that we conflate (1) TLS server fetching and managing its own OCSP staple for presenting to clients; with (2) the TLS client demanding a staple of the peer.
Solving this fully will require a new OCSP block keyword of peer
, and probably letting the ocsp{}
block be embedded in a tls{}
block, as originally spec'd.
In the meantime, given the split in administrative domains between "cluster/supercluster" and "leafnodes", it makes sense to just have the peer policy match for cluster/supercluster without an explicit peer
block, and turn off OCSP for leafnodes.
The trade-off which we are accepting with this PR is that the NATS server connecting as a leafnode to a hub is also losing the ability to verify the staple as presented by the hub. Fixing this will require the ability to set tls{ocsp{peer: ...}}
in config. In the meantime this is a withdrawal of functionality to get to a "more likely to work" deployment. We will fix more correctly in the near-ish future.
Add test for verify_and_map usage with ocsp Signed-off-by: Waldemar Quevedo <wally@nats.io>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This changes ocsp handling so that leafnode remote client connections behave more similarly to how regular nats clients work, rather than mimic the bidirectional verification that happens for routes/gateways.
Resolves #3959