Hi,
I’m getting the below error when I try to test the connection in my web service va based connector.
I tried passing the same token in the Web service saas connector. It’s working fine there
Could anybody help me with this, please?
There are several things to troubleshoot here, but considering the error message (connection reset), I suspect a firewall or proxy between the VA and the HTTP endpoint that is not cooperating on your end. Please try to use the nc command using the tb utility. See here: https://community.sailpoint.com/t5/IdentityNow-Connectors/Virtual-Appliance-Troubleshooting-Guide/ta-p/78735#toc-hId-447447802
Since the same token works with the Web Services SaaS connector, it doesn’t seem to be an authentication issue. The Connection reset error is usually related to network connectivity, firewall/proxy, or SSL trust between the Virtual Appliance and the target endpoint.
I’d recommend checking the ccg.log on the VA around the time of the failed test connection for any SSL handshake errors, proxy/network timeout messages, or additional exceptions that indicate why the remote host is resetting the connection. That should help narrow down the root cause.
@sandy_sandy I guess Firewall issues. Target application is blocking the Virtual Appliance (VA) or IdentityIQ server. you can check the port 443.
Thanks for the reply everyone,
Hi @sauvee ,
I tried using the nc command and the connection has been succeeded
Hello Sandy,
Since the nc test succeeded, basic connectivity from the VA to the endpoint looks okay. Is the Test Connection still failing in the connector, or has the issue been resolved now?
If it is resolved, please mark the correct reply as the solution so it helps others facing the same issue. If it is still failing, please share the latest error from ccg.log around the test connection time so we can continue checking.
Thanks.
@sandy_sandy , as mentioned here as well, please check the ccg.log when performing a test connection. You may even need to turn up the verbosity of your logging using these settings:
Hi @sandy_sandy
Connection reset + HTTP Error Code 0 = VA never completed the TLS handshake. The connection opened but got dropped before any HTTP response.
Quick checks in order:
- Test reachability from the VA
curl -v --connect-timeout 10 https://:<host>:<port>
Fails? → Firewall rule missing. Fix that first. - Check CCG logs
tail -f /home/sailpoint/log/ccg.log | grep -i "socket|ssl|error",this tells you exactly where the handshake broke. - Common culprits :
3.1. TLS version mismatch between VA JVM and target
3.2. VA IP not whitelisted on the target side
3.3. Wrong URL scheme (http vs https)
Try above and post any logger here if you have, will be able to guide you better.
@sauvee @punna0001 @Bapu-Gogu ,
Thanks for the replies,
I got this response for the below curl command I ran in my VA
curl -v https://test.com/
Host test.com:443 was resolved.
- IPv6: (none)
- IPv4: *****
- Trying ****
- ALPN: curl offers h2,http/1.1
- TLSv1.3 (OUT), TLS handshake, Client hello (1):
- CAfile: /etc/ssl/certs/ca-certificates.crt
- CApath: /etc/ssl/certs
- Recv failure: Connection reset by peer
- TLS connect error: error:00000000:lib(0)::reason(0)
- OpenSSL SSL_connect: Connection reset by peer in connection to test.com:443
- closing connection #0 curl: (35) Recv failure: Connection reset by peer
Can you do a curl -vvv to get very verbose information on the call?
I suspect it is indeed a tls issue and that the VA doesn’t have the proper certificate(s) in its certificate store.
Hi @sauvee ,
please find the information form the curl -vvv command
***** [0-x] == Info: [READ] client_reset, clear readers
***** [0-0] == Info: Host test.com:443 was resolved.
***** [0-0] == Info: IPv6: (none)
***** [0-0] == Info: IPv4: *****
***** [0-0] == Info: [HTTPS-CONNECT] adding wanted h2
***** [0-0] == Info: [HTTPS-CONNECT] added
***** [0-0] == Info: [HTTPS-CONNECT] connect, init
***** [0-0] == Info: Trying *****:443…
***** [0-0] == Info: [HTTPS-CONNECT] connect → 0, done=0
***** [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) → 0, done=0
***** [0-0] == Info: [HTTPS-CONNECT] adjust_pollset → 0, 1 socks
***** [0-0] == Info: [SSL] cf_connect()
***** [0-0] == Info: [SSL] ossl_connect, step1
***** [0-0] == Info: ALPN: curl offers h2,http/1.1
***** [0-0] == Info: [SSL] ossl_connect, step2
***** [0-0] => Send SSL data, 5 bytes (0x5)
0000: …&
***** [0-0] == Info: TLSv1.3 (OUT), TLS handshake, Client hello (1):
***** [0-0] => Send SSL data, 1574 bytes (0x626)
0000: …“…kOo…/.:…H…2”…_<2…F.. .1>0(.f{.kO…Rn#.fG.4.
0040: Z…K.^.<…,.0…+./…$.(.k.#.'.g…9…3…=.
0080: <.5./…!..test.com…
0580: ..npI@z…|N.m/..@.6.&B…;(.s:..&..lx@..4..s..B8S..b…9"
05c0: .L…|.tq.[;-..?}y. ..z…A…]…5V…f…F$s..
0600: .;… …l..<..#./.4i.#…vxY^…|
***** [0-0] == Info: [SSL] ossl_bio_cf_out_write(len=1579) → 0, 1579
***** [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) → 81, 0
***** [0-0] == Info: [SSL] ossl_populate_x509_store, path=/etc/ssl/certs/ca-certificates.crt, blob=0
***** [0-0] == Info: CAfile: /etc/ssl/certs/ca-certificates.crt
***** [0-0] == Info: CApath: /etc/ssl/certs
***** [0-0] == Info: [SSL] SSL_connect() → err=-1, detail=2
***** [0-0] == Info: [SSL] SSL_connect() → want recv
***** [0-0] == Info: [SSL] cf_connect() → 0, done=0
***** [0-0] == Info: [HTTPS-CONNECT] connect → 0, done=0
***** [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) → 0, done=0
***** [0-0] == Info: [SSL] adjust_pollset, POLLIN fd=4
***** [0-0] == Info: [HTTPS-CONNECT] adjust_pollset → 0, 1 socks
***** [0-0] == Info: [SSL] cf_connect()
***** [0-0] == Info: [SSL] ossl_connect, step2
***** [0-0] == Info: Recv failure: Connection reset by peer
***** [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) → 56, 0
***** [0-0] == Info: [SSL] SSL_connect() → err=-1, detail=5
***** [0-0] == Info: TLS connect error: error:00000000:lib(0)::reason(0)
***** [0-0] == Info: OpenSSL SSL_connect: Connection reset by peer in connection to test.com:443
***** [0-0] == Info: [SSL] cf_connect() → 35, done=0
***** [0-0] == Info: [HTTPS-CONNECT] connect, all attempts failed
***** [0-0] == Info: [HTTPS-CONNECT] connect → 35, done=0
***** [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(block=0) → 35, done=0
***** [0-0] == Info: [HTTPS-CONNECT] Curl_conn_connect(), filter returned 35
***** [0-0] == Info: [WRITE] [OUT] done
***** [0-0] == Info: closing connection #0
curl: (35) Recv failure: Connection reset by peer
I would check which certificate is being used by the API you are calling and then import that certificate into the VA certificate store.
Use openssl command to get the certificate:
openssl s_client -connect server.domain.local:port
Copy the output into a new file and place it under:
/home/sailpoint/certificates
Then restart CCG
sudo systemctl restart ccg
Just a question, Is it mandatory to pass the certificate? To generate the token I’m using a private key, since it’s a JWT based authentication
I’ll try adding the certificate into the va and test it once again
Thanks
When communicating with your application, SailPoint must trust your public key certificate before making any API calls using HTTPS protocol.
This PKI certificate must be added to your Virtual Appliance by following the steps described by @sauvee
This certificate is different from the private key used for JWT authentication.
Try out curl from the VA itself and if possible share here, can try figure out the issue if nothing sensitive info is there in your dev. Most probably a cert issue.
Hello Sandy,
No, the JWT private key and the HTTPS certificate are two different things.
The private key is used later for JWT authentication. But your curl output shows the connection is failing before it even reaches the authentication/token stage. The VA sends the TLS ClientHello and then the target resets the connection, so this looks more like TLS/network/WAF behavior from the target side, not a JWT issue.
Also, since the Web Services SaaS connector works, that only proves the token/API works from SailPoint cloud path. The VA-based connector is coming from your VA network path, so the target may still be blocking or rejecting the VA traffic.
Here is how I would work through it:
First, confirm the API/WAF/load balancer allows the VA outbound/public IP. Then run this from the VA:
openssl s_client -connect <host>:443 -servername <host> -showcerts
If it returns the certificate chain, copy the required root/intermediate PEM certs to /home/sailpoint/certificates/ on every VA in the cluster. Then restart CCG:
sudo systemctl restart ccg
After restart, check /home/sailpoint/log/ccg-start.log and ccg.log to confirm the cert import. If openssl also gets reset before showing the certificate, then importing the cert alone would not fix it. In that case the target side needs to check TLS policy, SNI/hostname, cipher/TLS version support, WAF rules, and VA IP allowlisting.
So short answer: certificate is not part of the JWT token generation, but the VA still must trust the API server certificate and the target must allow the VA TLS connection before JWT auth can even happen.
Hi @sauvee ,
I uploaded the certificate into the certificates folder and tried the test connection again, but it’s still showing the same error
Did you make sure to reboot the ccg:
sudo systemctl restart ccg
Yes I did restart the ccg
@sandy_sandy with this command :
openssl s_client -connect host_name:443 -showcerts
Are you able to see the server certificate from the VA ?