Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I have two RHEL 7.2 servers and running below command. Though both servers are made in a similar way, one server can get the curl output with the required token, and another server not.
In below output, auth.lb.pre.vuspoint.com is load balancer and I can ping it from this server. This LB is pointing to two servers on backend, which have tokens. Below command (which is failing on this server, but working on other) is supposed to get token from any of those backend server.
Code:
[root@serv-portal3 ~]# curl -k --location --request POST "https://auth.lb.pre.vuspoint.com/auth/realms/PRE-REALM/protocol/openid-connect/token" --header "Content-Type: application/x-www-form-urlencoded" --data "client_secret=fd68ddbf-5740-4912-b714-1aaeb453fafc&grant_type=password&client_id=snapshotui_1.1&username=snapshotmpctestuser&password=snapshotmpc"
curl: (35) TCP connection reset by peer
[root@serv-portal3 ~]#
[root@serv-portal3 ~]# curl -v -k --location --request POST "https://auth.lb.pre.vuspoint.com/auth/realms/PRE-REALM/protocol/openid-connect/token" --header "Content-Type: application/x-www-form-urlencoded" --data "client_secret=fd68ddbf-5740-4912-b714-1aaeb453fafc&grant_type=password&client_id=snapshotui_1.1&username=snapshotmpctestuser&password=snapshotmpc"
* About to connect() to auth.lb.pre.vuspoint.com port 443 (#0)
* Trying 172.30.74.73...
* Connected to auth.lb.pre.vuspoint.com (172.30.74.73) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* NSS error -5961 (PR_CONNECT_RESET_ERROR)
* TCP connection reset by peer
* Closing connection 0
curl: (35) TCP connection reset by peer
[root@serv-portal3 ~]#
[root@serv-portal3 ~]# openssl s_client -connect auth.lb.pre.vuspoint.com:443
CONNECTED(00000003)
write:errno=104
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 249 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
---
[root@serv-portal3 ~]#
There is no firewall between this server and loadbalancer and to another server also, where LB is pointing. Network team says that it is server issue and things are working fine on their end, though I don't believe it always. But above output is not sufficient to prove if it is network side issue.
Please suggest, what I am missing and should be checked.
I am almost certain you don't get this on the other server:
Code:
NSS error -5961 (PR_CONNECT_RESET_ERROR)
Since my knowledge in the area of certificates and https is at an embarrassing level, I will leave it up to you to use this error message. DuckDuckGo produces some results. Quite likely, your two local servers have different certificate/keyring/key-infrastructure/cryptography setups.
Have you done the same test, verbose curl and openssl, on the functioning server?
A little more searching (openssl s_client 104) provides suggestions like different openssl versions, you should use TLS anyway, you might be behind a firewall.
I would also trace and analyze the network traffic on both connections. There must be a difference.
Last edited by berndbausch; 09-21-2019 at 04:36 AM.
Reason: typo
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
