dlenski
--servercert and redirect
In my case openconnect-gp connects first to one server which redirects to an other. Those servers have different certs. If I give no '--servercert' the first server is not challenged and connects but second gives:
To trust this server in future, perhaps add this to your command line: --servercert xyz
Now if I give the above the first server is challenged but since the cert is for the second it gives the above with
--servercert abc
If I give that the first goes OK but second server fails
Is there a way to deal with both servers with some parameters, or is some new code needed?
I'm not sure if this situation is particular to gp or general openconnect issue.
This is a very good question, and it will take me some time to explain the issue in detail.
In the short term, the best way to deal with this is to ignore the first server (the "portal" in GlobalProtect's terminology) and go straight to the second server (the "gateway" in GP's terminology). Instead of openconnect -u username --prot=gp vpn-portal.company.com, do openconnect -u username --prot=gp vpn-gateway.company.com.
Does that work for you?
I'm not sure if this situation is particular to gp or general openconnect issue.
It's a general openconnect issue, exacerbated by the fact that GlobalProtect "portal" servers act as CAs for the "gateway" servers :frowning_face:
No go! It gives:
Please enter your username and password
Password:
POST https://vpn-gw1.company.net/global-protect/getconfig.esp
Attempting to connect to server 123:123:123:123:443
Connected to 123.123.123.123:443
SSL negotiation with vpn-gw1.company.net
Server certificate verify failed: signer not found
Connected to HTTPS on vpn-gw1.company.net
Got HTTP response: HTTP/1.1 200 OK
Date: Wed, 03 Oct 2018 19:20:21 GMT
Content-Type: application/xml; charset=UTF-8
Content-Length: 0
Connection: keep-alive
ETag: "40d1-756-5a7203f7"
Pragma: no-cache
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Thu, 19 Nov 1981 08:52:00 GMT
X-FRAME-OPTIONS: DENY
Set-Cookie: PHPSESSID=66634dd81cab216272d604e661c69a1b; secure; HttpOnly
Set-Cookie: PHPSESSID=66634dd81cab216272d604e661c69a1b; secure; HttpOnly
Strict-Transport-Security: max-age=31536000;
X-XSS-Protection: 1; mode=block;
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'self';
Ignoring unknown HTTP response line ' script-src 'self' 'unsafe-inline';'
Ignoring unknown HTTP response line ' style-src 'self' 'unsafe-inline';'
HTTP body length: (0)
Unexpected 200 result from server
Failed to obtain WebVPN cookie
The first server connect authenticates with 'Duo' (with my phone). That lacking the second is bound to fail.
So can't skip the first server.
One way to fix the openconnect code would be to expand the --servercert option so that you can give a list e.g. in following way:
--servercert servername1#cetificate1,servername2#cetificate2
and change the code to use the cert matching with server name. Or just the list of certs, and code would try them all. Both would be relatively easy to code (into openconnect_check_peer_cert_hash).
… log …
Hmm… the gateway server is giving you a very… odd response here. If you're willing to send me the gateway server address privately via email, that'd help me understand how to support this case.
If not, please checkout the latest build of the master branch, which may more gracefully work around at least part of what's causing the problem here.
The first server connect authenticates with 'Duo' (with my phone). That lacking the second is bound to fail.
So can't skip the first server.
You would be surprised, actually. The administrators who run these VPNs don't really understand how the protocol works, and it's quite likely that it's possible to bypass the 2FA by going straight to the gateway. :stuck_out_tongue_closed_eyes:
Another (temporary) solution is to extract the signing certificate from the first server, the portal. Use test-globalprotect-login.py and run test-globalprotect-login.py https://vpn-portal.company.com/global-protect/getconfig.esp, and then extract the PEM-formatted <root-ca> bits, save that as portal.pem, and then run openconnect --prot=gp --cafile=portal.pem --servercert FINGERPRINT_OF_PORTAL vpn-portal.company.com. That will cause openconnect to trust the gateway certificates — which are signed by the portal's "CA" certificate.
One way to fix the openconnect code would be to expand the --servercert option so that you can give a list e.g. in following way:
This will be somewhat tricky to implement in a way that might be approved for merging upstream. Adding a mechanism to make openconnect trust the certs sent by the portal as valid for the server may be easier.
It may well be that they don't understand fully what they are doing. But the arrangement with two servers is intentional. As mentioned the first is there to authenticate the user with password and the Duo authentication system (it contacts my phone for final authentication). As I have understood (not 100% sure) the first server sends temporary authentication data to gateway server as well as to my end. Thus the first authentication is needed for the second.
So both servers must be connected. It would probably work OK if openconnect could be somehow instructed not to check the first server's cert only of the second.
Extracting the CA cert (to pem-file) did also work, and '--servercert' was not needed at all; still no complaints about certs. But I would prefer not to use the pem-file (and the python script to get it). I'm setting things also for my coworkers (IT is of no help). If getting the pem-file could be made automatic it would be fine.
Did you mean that giving and checking the cert per server name might be easier approved for merging?
Unfortunately I'm not authorized to give the portal for your testing. You would need a passwd and our IT should approve your phone number for Duo application to work. They will not allow that.
Here is the log of a successful connection (without the pem-file):