-
Notifications
You must be signed in to change notification settings - Fork 140
Description
Proposed change
At present, there's nats account tls
which can report upon TLS information after successfully connecting and authenticating.
If the client can not get that far (bad auth credentials, or TLS verification failure) then this does not work.
Fixing this with the current command would require changing the nats.go
library to propagate out partial connection objects even upon connection failure and seems fraught. It seems likely that we would want a different approach for "raw connection-layer TLS reporting, minimal-if-any NATS protocol". I have done this many years ago, adding support for NATS into a multi-protocol Perl TLS checker, so I know that the amount of NATS protocol knowledge needed is absolutely minimal.
The issue really is around design and making sure we know what to connect to, if bypassing the regular connection setup code. Which comes down to maintainer comfort.
Are there any thoughts around if this is likely to be welcome at all? Or should be proven out in another tool first?
Use case
Debug why a TLS certificate is rejected by a NATS client.
Debug why TLS-based authentication might be failing.
Debug lower-level connection issues, discovering bad certs, or load-balancer interception, or the like.
Contribution
I can.