Info call fails due to invalid certificate on server

[lopesra]

Hi, I really appreciate you setting up and maintaining this project. I've spent days dealing with Checkpoint already.

When calling snx-rs -m info -s <IP_ADDRESS> I get this response:

Error: error sending request for url (https://<IP_ADDRESS>/clients/): error trying to connect: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (self-signed certificate in certificate chain)

Caused by:
    0: error trying to connect: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (self-signed certificate in certificate chain)
    1: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (self-signed certificate in certificate chain)
    2: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091:

The issue is most probably that the host system is using an invalid certificate. When requesting the portal IP address via the browser you are presented a warning.

Could you add an option to bypass invalid certificates in this case? I already tried running the command as snx-rs -m info -H true -s <IP_ADDRESS> with the same result.

I am running version 0.5.1-1 on Manjaro.

[ancwrd1]

Hi, it has a command line parameter -H true or --no-cert-check=true to bypass certificate check.

[ancwrd1]

Ah sorry, I didn't notice that you already tried it. It also has an option -k or --ca-cert to specify an additional CA root cert to trust, in PEM or DER format. You could try extracting it from the browser (the root cert from the returned chain).

[lopesra]

Thanks for your quick reply. I will give a try and get back to you.

[lopesra]

Hi @ancwrd1. With the downloaded certificate and command snx-rs -m info -H true -s <IP_ADDRESS> -k cert.pem it fails with the same error. I also doubled checked whether cert.pem is readable and is picked up by the application (changed filename to check if running the command throws an error).

[ancwrd1]

Does your server return a single certificate or a chain of them? If it's a single self-signed cert you should use it, otherwise use the root one from the returned chain, the one which has the same subject and issuer. You could check it also with openssl:

openssl s_client -showcerts -connect serveraddress:443

[lopesra]

Hi @ancwrd1 , sorry for the late reply. The host did run a certificate chain. I just extracted the root certificate and ran the command again with the same result.

Just to verify that it was the correct certificate I ran the command again with another cert in the chain, resulting in this error but this is to be expected:

Error: error sending request for url (https://<IP_ADDRESS>/clients/): error trying to connect: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (CA certificate key too weak)

Caused by:
    0: error trying to connect: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (CA certificate key too weak)
    1: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (CA certificate key too weak)
    2: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091:

The main issue is still what was posted initially: Error: error sending request for url (https://<IP_ADDRESS>/clients/): error trying to connect: error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:ssl/statem/statem_clnt.c:2091: (self-signed certificate in certificate chain)

[ancwrd1]

Hmm, ok. Perhaps I could try to load openssl legacy crypto provider. I think the weak algorithms are disabled by default.

[ancwrd1]

Ah sorry, this was another issue.

[ancwrd1]

If you can build the project yourself you can modify http.rs at line 153 to have:

        if self.0.no_cert_check {
            builder = builder.danger_accept_invalid_hostnames(true);
            builder = builder.danger_accept_invalid_certs(true);
        }

And see if it helps.

[lopesra]

I will try and report back.

[lopesra]

I just built it and the info call is working well with the added parameter! However, I am stuck at another issue after running connect. Everything goes through as it should and an I am able to enter an OTP. After successful validation of the OTP I get stuck with this error after the connection was already successful. This looks more like a local networking issue but I can't figure it out. (I anonymized IPs and hashes)

2024-01-23T13:50:12.521375Z DEBUG hyper::client::connect::http: connecting to XXX:443
2024-01-23T13:50:12.539736Z DEBUG hyper::client::connect::http: connected to XXX:443
2024-01-23T13:50:12.625799Z DEBUG hyper::proto::h1::io: flushed 297 bytes
2024-01-23T13:50:12.656575Z DEBUG hyper::proto::h1::io: parsed 8 headers
2024-01-23T13:50:12.656627Z DEBUG hyper::proto::h1::conn: incoming body is content-length (906 bytes)
2024-01-23T13:50:12.656687Z DEBUG hyper::proto::h1::conn: incoming body completed
2024-01-23T13:50:12.661586Z DEBUG snx_rs::platform::linux::xfrm: Source IP: XXX
2024-01-23T13:50:12.661603Z DEBUG snx_rs::platform::linux::xfrm: Target IP: XXX
2024-01-23T13:50:12.702046Z DEBUG snx_rs::platform::linux::xfrm: Sending isakmp probe to XXX
2024-01-23T13:50:12.716310Z DEBUG snx_rs::platform::linux::xfrm: Received isakmp reply from XXX: srcport: 4500, dstport: 4500, hash: xyz
2024-01-23T13:50:12.752342Z DEBUG snx_rs::platform::linux::net: Adding route: XX/16 via snx-vti
Error: RTNETLINK answers: File exists

[ancwrd1]

hmm, could be multiple reasons: you already have a specified route in your system added by some other app (could be checked with "ip route show", or the checkpoint GW returns a duplicate route, or you have IP range conflict. Usually VPN subnet should be different from your local one. Try with trace log level instead of debug, it will show requests and responses, and also the commands which run to set up routing.

[lopesra]

Thanks for debugging this with me. I know this is hardly an issue with your package but maybe we can sort this out for others to come. ip route show returns these entries:

default via 192.168.178.1 dev wlp0s20f3 proto dhcp src 192.168.178.20 metric 600 192.168.178.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.178.20 metric 600

These are just default entries for my own network. Running snx-rs -H true -s <IP_ADDRESS> -e ipsec -o vpn -l debug adds the snx-vti line: 10.153.0.0/16 dev snx-vti proto kernel scope link src 10.153.133.106

When I manually remove it with ip route flush 10.153.0.0/16 and run the command again, it still fails with ERROR: RTNETLINK answers: File exists. Is it trying to add another default route? Maybe this needs to be a replace instead of an add.

[ancwrd1]

Could you check what routes are returned back from the VPN server? They will be visible in the ClientSettings response as network ranges. I am wondering if the server returns multiple overlapping routes. Anyway, we can simply ignore the error in the code, but I'd like to get down to the actual reason.

[ancwrd1]

The responses are visible with the trace level.

[lopesra]

ClientSettingsResponse returns a massive block of NetworkRanges of which some of them are definitely overlapping. I did not include them as anonimyzing would be an hour's work.

[ancwrd1]

Alright, thanks. I will check how can it be fixed in a consistent way.

[ancwrd1]

Please try the recent main branch. It should be working now.

[ancwrd1]

I have also added a dangerous option --ignore-server-cert to disable all certificate validations.

[lopesra]

Yes, perfect. The connection is going through now. Does not work through the browser yet but I'm guessing that is due to me running it through the IDE terminal. Appreciate everything you're doing here @ancwrd1 .