On the first isn't te same issue as ttps://bugs.kde.org/show_bug.cgi?id=348318 but is closly related. When VPN server certificate is untrusted (self-signed, or signed by other untrusted) and i "make it trusted" by fill path to them (eg. *.cer file) in connection edit window "CA Certificate". Now after this i don't get "Server certificate verify failed: signer not found", but still I can not connect, because now i have get "Server certificate verify failed: certificate does not match hostname" Reproducible: Always Steps to Reproduce: 1. Try to connect with openconnect plugin to server with untrusted certificate which CN differs from the server name. It may be "emulated" by change DNS name to ip address (The vast majority of certificates are not issued for ip address). Eg. try to connect to https://144.92.42.108/ instead of https://dept-ra-cssc.vpn.wisc.edu/ (It is address from https://bugs.kde.org/show_bug.cgi?id=348318) 2 So in connection edit window in Gateway type: 144.92.42.108 and save new profile. 3. Connect with ten new profile. Actual Results: When trying to connect to such address, you will receive: POST https://144.92.42.108/ Attempting to connect to server 144.92.42.108:443 SSL negotiation with 144.92.42.108 Server certificate verify failed: certificate does not match hostname SSL connection failure: Error in the certificate. Failed to open HTTPS connection to 144.92.42.108 Expected Results: Allow connection (not verifiy certificate chain, CN and the host name or even the expiration date of the certificate) when a certificate is explicitly indicated as trusted (when editing a connection), or when the user confirms that trust such certificate (when the window appears with the details of the certificate) Such actions are possible by directly run openconnect from the command line and also was possible in version plasma-nm-5.3.2 (and erlier). Currently it is not possible to connect to the VPN server using such a certificate, using NetworkManager
I believe that this bug got fixed in Plasma 5.5.1, can you confirm that?
As of 4/22/16, Debian Testing distro, this is an issue. Background: Debian Testing, KDE desktop install from the "tasksel" menu. There is nothing fancy going on with the install. Cisco VPN host isn't going to get their cert signed. 1. Add Openconnect network via the NetworkManager KDE applet. 2. Launch the openconnect network via the KDE applet. 3. VPN Secrets GUI opens with the appropriate IP address. 4. Click the "connect" button. 5. GUI opens with "Check failed for certificate from VPN server "xx.yy.zz.aa" Reason: signer not found. Accetpt it anyway?" Select "okay" 6. "Accept anyway" goes away and VPN secrets GUI is refreshed with error "Failed to open HTTPS connection to xx.yy.zz.aa. Expected behavior: Enter user password Actual behavior: No opportunity to enter a password, no opportunity to ignore cert check. Workaround, as root "openconnect --no-cert-check xx.yy.zz.aa"
FYI, Debian's package information. plasma-nm 4:5.4.3-1 amd64 Plasma5 networkmanager library.
Is this still reproducible with Plasma 5.5.1 or newer?
Closing. Please reopen if this issue is still reproducible with latest Plasma release.