On Sun, 2013-02-03 at 04:18 -0500, Brian D Peyser PhD wrote: > I noticed that when I tried to connect repeatedly, the IP address > sometimes changed (and I would get different server certificates). There > are apparently multiple IPs for the same host name. That finally gave me > an idea, and I just made a connection with one of the IP addresses for > the gateway instead of the "correct" hostname. I got a dialog asking if > I would accept the certificate, I accepted it, and it connected! I'm not > sure where the problem is, but at least it is working for now. Right. What happens is the GUI side will connect to the server and do the proper certificate validation (including asking the user if necessary). Then it hands off three pieces of information to the openconnect process that's run to make the actual connection ? the server's hostname, a SHA1 of the SSL certificate, and the webvpn cookie which is what's used to authenticate. If you have multiple different servers on a single round-robin DNS name, that explains why you see this problem. When it makes the final connection, it gets a *different* server to the one it used for authentication, and the SHA1 of the cert obviously doesn't match. The fix for this isn't in the nm-auth-dialog; it's in openconnect itself. We already update vpninfo->hostname when we get HTTP redirects for load balancing, etc. We should also update it in connect_https_socket() in ssl.c, to contain a numeric IP address, if we've had to do a DNS lookup there. That'll ensure that any future reconnections are to the *same* host. I'll have a look at that and give you a patch to test... maybe tomorrow. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 6171 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20130203/71ca3ac3/attachment.bin>
