Leafnode TPM access #6190
Unanswered
ZarkoRunjevac
asked this question in
Q&A
Leafnode TPM access
#6190
Replies: 3 comments 6 replies
-
|
From your leafnode perspective, it is not using TLS (unless the Your "hub" is configured to accept TLS connections and is configured to require that the TLS protocol be initiated first, before it can start with the NATS protocol (which in the case of the "hub" would be to send the INFO protocol to the remote). If the TLS handshake fails with an error as described above, it means that the proper handshake was not initiated, which since in this case you have stunnel in the middle, you need to look at that to understand why it is not doing it. If for some reason "stunnel" is expecting a plain protocol prior to the TLS handshake, like NATS normally does when not configured with |
Beta Was this translation helpful? Give feedback.
0 replies
-
|
@ZarkoRunjevac Was the answer helpful? Did you figure out what the issue was? |
Beta Was this translation helpful? Give feedback.
4 replies
-
|
Thank you very much for answer. But unfortunately did not solved my issues. For the first connection leafnode starts connection without tls(how it should): but for reconnect it start tls connection, and that connection fails with stunnel? |
Beta Was this translation helpful? Give feedback.
-
|
I understand that you are trying different things, but we start to depart quite a bit from the original configuration. Adding websocket (in the remote) is simply changing the url to Few things:
So the fact that one side is configured for TLS and the other side is not, and relies in an intermediary to do the TLS, is not something that we have planned for. On top of that, if the "hub" is configured as a cluster, it would also send the list of all servers' LeafNode port in its cluster so that the remote has knowledge of these multiple URLs when trying to reconnect. This can be disabled with We generally discourage the use of load balancer or things in between NATS (client/servers or servers/servers), so I am not sure if we plan to address that, which if we were we would probably need either an option to disable setting internally that the remote should use TLS based on the incoming INFO, or should not have done that in the first place. @derekcollison do you have an opinion? -- Edited -- Finally, @ZarkoRunjevac, something that may be obvious but that you need to make sure:
|
Beta Was this translation helpful? Give feedback.
-
|
Hi, thank you for a detailed answer.
Stunnel is not that flexible, I tried few options how to reset connection without success. |
Beta Was this translation helpful? Give feedback.
-
It may be already doing the right thing, I was just asking you to verify that what I described that must happens, happens. If it does not, then possible changes in the TLS handshake issue (receiving from the "hub" that the remote should use TLS) is moot because the rest of the NATS protocol would possibly fail. |
Beta Was this translation helpful? Give feedback.
-
|
@ZarkoRunjevac are you a Synadia customer? |
Beta Was this translation helpful? Give feedback.
2 replies
-
|
No, we are not. |
Beta Was this translation helpful? Give feedback.
-
|
ok no worries, we love our OSS ecosystem and do our best to support them, but we do prioritize paying customers on more advanced setups etc like this one. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
is it possible to access certificate and key from TPM using PKCS#11?
My leafnode is confiured as:
My current setup is that I forward traffic from leafnode to stunnel and in stunnel encrypt it and forward traffic to hub.
Hub tls is configured with option
I am getting error:
I think error is consequence of the fact that hub is expecting first tls handshake but it receives info message that is tls encrypted:
Beta Was this translation helpful? Give feedback.
All reactions