On Sun, 2016-04-10 at 22:53 -0400, Michael Welsh Duggan wrote:
Michael Welsh Duggan <mwd md5i com> writes:Dan Williams <dcbw redhat com> writes:On Tue, 2016-04-05 at 10:55 -0400, Michael Welsh Duggan wrote:Thomas Haller <thaller redhat com> writes:On Mon, 2016-04-04 at 22:09 -0400, Michael Welsh Duggan wrote:I'm having some difficulties using network-manager- openconnect. If I use openconnect directly: openconnect -c cert.pfx --authgroup=[GROUP] --no-xmlpost [SERVER] everything works just fine. When I use network-manager I get the following: Server requested SSL client certificate after one was provided Certificate Validation Failure This used to work (many months ago). I don't know whether an update of nm was why things changed, or if it was a change of the VPN server at work. I am using network-manager and network-manager-openconnect from Debian unstable: network-manager 0.9.10.0-1 network-manager-openconnect 0.9.8.6-1 I'm happy to provide more debugging information if someone would tell me what to provide.When nm-openconnect starts openconnect binary, it runs as a different user. Make sure that that user is able to access the certificate.And what user might that be? NetworkManager and nm-dispatcher are running as root, as is nm-openconnect-service. Also, if it could not access the certificates, I would expect a different type of error.nm-openconnect runs as root, but it spawns the actual openconnect process as the 'nm-openconnect' user for security. That user must be able to access your certificates. Unfortunately libraries like OpenSSL/GnuTLS don't have great verbose error reporting, and the "Certificate Validation Failure" message comes from there, most likely (since it's not part of nm-openconnect source). They don't report it to nm-openconnect, so nm-openconnect doesn't have a great way to get it back to you, the user.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): 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 Using client certificate 'mwd' Adding supporting CA 'MFCIssuer3Sierra.banner.multifactortrust3.com' SSL negotiation with [elided] Connected to HTTPS on [elided] Got HTTP response: HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Cache-Control: no-cache Pragma: no-cache Connection: Keep-Alive Date: Tue, 05 Apr 2016 20:42:00 GMT X-Frame-Options: SAMEORIGIN X-Aggregate-Auth: 1 HTTP body chunked (-2) POST https://[elided]/ SSL negotiation with [elided] Connected to HTTPS on [elided] Got HTTP response: HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Cache-Control: no-cache Pragma: no-cache Connection: Keep-Alive Date: Tue, 05 Apr 2016 20:42:00 GMT X-Frame-Options: SAMEORIGIN X-Aggregate-Auth: 1 HTTP body chunked (-2) Server requested SSL client certificate after one was provided POST https://[elided] Got HTTP response: HTTP/1.1 200 OK Content-Type: text/html; charset=utf-8 Transfer-Encoding: chunked Cache-Control: no-cache Pragma: no-cache Connection: Keep-Alive Date: Tue, 05 Apr 2016 20:42:00 GMT X-Frame-Options: SAMEORIGIN X-Aggregate-Auth: 1 HTTP body chunked (-2) XML POST enabledPing. Any ideas? Can I help debug this in any way?
The NetworkManager plugin ultimately executes the openconnect binary too. Can you see the command line arguments via `ps aux | grep openconnect`? If you don't manage to do that (because openconnect exits to quickly), spawn the nm-service as /usr/libexec/nm-openconnect-service --debug (similar to what is described here: https://wiki.gnome.org/Projects/Net workManager/Debugging#Debugging_NetworkManager-openvpn and see if you find the arguments there. As you have it working when spawning the process manually, pay attention to the differencees to nail it down. Thomas
Attachment:
signature.asc
Description: This is a digitally signed message part