On Sun, 2016-04-10 at 22:53 -0400, Michael Welsh Duggan wrote:
I have verified that nm-openconnect has read access to both the cert and key files. The problem persists. Here is the log (with some addresses elided):
At this point, your nm-auth-dialog is basically doing the same thing as you'd get with 'openconnect --authenticate'. It should be using the *same* libopenconnect.so shared library to do this authentication. So... unless you have a bizarrely hacked installation where the NetworkManager bits are linked against one version of libopenconnect while the installed 'openconnect' binary is newer, they *really* ought to be behaving the same. Unless they're configured differently. The first thing that stands out is...
POST https://[elided] Attempting to connect to server [elided]:443 Using certificate file /home/md5i/private/certs/vpn-mwd.crt Using private key file /home/md5i/private/certs/vpn-mwd.key
Your example of a 'successful' run with /usr/sbin/openconnect didn't use those. You used a PKCS#12 'cert.pfx' instead. Is that because we still don't let you select a PKCS#12 file in the properties dialog? You can set it manually by editing the config file (or perhaps with nmcli, although I don't know if that actually works for vpn-specific properties)? Thankfully there's a GSoC project this year to fix the SSL certificate choosers once and for all, and all this crap should start working nicely. ...
Server requested SSL client certificate after one was provided
So you sent a certificate which is *different* to the one in your previous "working" example, and the server continued to ask you for a new certificate. I'm going to stop hypothesising here; can you try 'openconnect --authenticate' runs with the above-listed cert/key, and with your original cert.pfx? DO NOT SHOW THE WEBVPN COOKIE. As discussed in the reply I sent a few minutes ago, it represents your session — it's all we need to actually connect to your VPN. In the logs it does get elided automatically, but when you use --authenticate, emitting it is kind of the *point* so it will still be seen.
Ping. Any ideas? Can I help debug this in any way?
For reference, openconnect-specific things are likely to get a faster response from me on the openconnect-devel lists infradead org mailing list. I only look at the NM list from time to time. Unless someone explicitly adds me to Cc, which probably would have helped here (Dan, Thomas). -- David Woodhouse Open Source Technology Centre David Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature