Skip to content
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

Problem connecting with TLS #44

Open
elettrico opened this issue Jan 2, 2025 · 3 comments
Open

Problem connecting with TLS #44

elettrico opened this issue Jan 2, 2025 · 3 comments
Assignees

Comments

@elettrico
Copy link

Hi, first of all, thanks for this software and keep up the good work.
I'm trying to connect to NATS using TLS with self signed certificates.
I've no problem with others clients, but whenI try with NATS-NUI it can't connect, the log show:

disconnected - read tcp 172.x.x.x:41232->192.x.x.x:8800: i/o timeout

and the NATS log show:

[ERR] monitoring: TLS handshake error from 172.x.x.x:60522: read tcp 192.x.x.x:8800->172.x.x.x:60522: i/o timeout,

The certificate files are the very same other clients are using, so I'm a little lost. is there a way to have a more detailed log?

@pricelessrabbit
Copy link
Collaborator

pricelessrabbit commented Jan 5, 2025

Hi, so first of all, the logs that you see are coming directly from the go nats client and looks like for some reason a timeout occurs.

I tried to reproduce the problem but i never got a timeout caused by self-signed certs.

Pls, check this working example setup an maybe twaking it we can find the issue 🐰

@pricelessrabbit pricelessrabbit self-assigned this Jan 5, 2025
@elettrico
Copy link
Author

elettrico commented Jan 9, 2025

Hi, sorry for the delay. I've asked for a spare machine so I can try the working example, anyway I noticed "verify: false" in the nats.conf, I don't have that option.
I've also tried putting nats servers and nats-nui in the host network, but I receive the same error:

[1] 2025/01/09 18:20:58.338997 [ERR] monitoring: TLS handshake error from 127.0.0.1:42342: read tcp 127.0.0.1:8800->127.0.0.1:42342: i/o timeout,
[1] 2025/01/09 18:21:44.068614 [ERR] monitoring: TLS handshake error from 127.0.0.1:60732: read tcp 127.0.0.1:8800->127.0.0.1:60732: i/o timeout

anyway, testing TLS with the same certificates works ok:

openssl s_client -connect desa.mydomain.com:8800   -tls1_2 -status -msg -debug   -CAfile /etc/ssl/desa.mydomain.com/server_chain_root_ca.crt   -key /etc/ssl/desa.mydomain.com/server.key   -cert /etc/ssl/desa.mydomain.com/server.crt > test.txt

Can't use SSL_get_servername
depth=3 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
verify return:1
depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Global Services CA SHA2
verify return:1
depth=1 C = UY, O = mydomain S.A., OU = IDdigital, CN = mydomain SSL Domain Validated
verify return:1
depth=0 CN = *.desa.mydomain.com
verify return:1

also with curl the connection works without any problem:

curl --trace trace.log https://desa.mydomain.com:8800 --cacert /etc/ssl/desa.mydomain.com/server_chain_root_ca.crt --cacert /etc/ssl/desa.mydomain.com/server.crt --key /etc/ssl/desa.mydomain.com/server.key
<html lang="en">
        [... snip ...]
        <a href=https://github.com/nats-io/nats-server/tree/v2.10.21 class='version'>v2.10.21</a>
        </div>
        <br/>
        <a href=./varz>General</a>
        <a href=./jsz>JetStream</a>
        <a href=./connz>Connections</a>
        <a href=./accountz>Accounts</a>
        <a href=./accstatz>Account Stats</a>
        <a href=./subsz>Subscriptions</a>
        <a href=./routez>Routes</a>
        <a href=./leafz>LeafNodes</a>
        <a href=./gatewayz>Gateways</a>
        <a href=./raftz>Raft Groups</a>
        <a href=./healthz class=last>Health Probe</a>
    <a href=https://docs.nats.io/running-a-nats-service/nats_admin/monitoring class="help">Help</a>
  </body>

I've also tried an insecure connection, but in this case I can't get the connection working at all. So, I'm thinking, is there any problem if the monitoring port is other than 80? In my case it's 8800. I'm lost :P

@elettrico
Copy link
Author

More data: if I open my browser, point to the nui interface and create a new connection to my nats cluster, it get the pink (X) icon and never get online. Anyway, if I open directly the connections api /api/connection/ I get the json representing it, but if I try to open the /ws/sub api with the connection id /ws/sub?id=3d782bcb-485a-4b94-ad40-3ab1754e1dd4 I get an "upgrade required" message. IDK if it's ok, but maybe it can be useful

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants