This is odd. You show NetworkManager complaining that no "agents" are available to handle the server login. And you show a screenshot of an "agent" which is currently attempting to do just that.

Hm, in the screenshot you showed me, you need to click the unlabelled "connect" button in the top right-hand corner, to the right of the server's hostname. That isn't obvious, is it?

It's designed to let you choose which server you want to connect to, but that's not really helpful if there's only *one* server that it knows about. We should make it automatically connect in that case...

On Cisco ASA there 2 ways check users. One way is check used DB and another user cert. I have working profile where user checked trough DB. Where you type user name and press log in button, then it validate user and give assigned group profile for this user on ASA.

And profile where users check through cert not working, because user cert located on local machine and it should check the certs and then prompt for login.
When I am using cert based it just trying go to login prompt without validation and this one will fail for sure.

Sorry, I'm not quite sure what you're telling me.

You have two profiles. One uses username/password authentication, and works fine?

The other uses certificate authentication, and doesn't work? That's the one you showed the screenshot and log from?

You do still need to click the 'connect' button in the top right-hand corner before it will connect and present your certificate though. Click the 'Automatically start connecting next time' checkbox first.

If you *still* get presented with a username/password prompt, then we have another bug and we'll try to debug that then...

Hello David,
Sorry can't reply sooner,
Yes on open connect have two ways how I can connect.

1. Group, Username and Password.

Explanation: In this method I enter only hostname and port in new profile and save. Next when from menu I select vpn connection I got small screen with "Login" button and another connect icon in right top corner. I press connect button and it send request to ASA and pull assigned group for this user. Then I fill username and password and press Login.


2. User certificate authentication, Group Username and Password.

Explanation: In this method I enter hostname, port and point to CA cert and personal user cert cert and private key and then click save. When I trying connect it should first validate user certificates with ASA, then it should present login box. Where you fill all information and press Login button.
In this case when I press in right corner connect icon it just trying do as described in first method and not validate cert first that why getting the error. This method I tested in Firefox. I uploaded cert to  browser store than access url https://hostname:port then pop up widow is asked which cert I want to use for user validation. Selected right cert, and pressed "remember my choice" and after 3 sec log in page is show up. Fill username and password and any connect start connection procedure.

Thanks for the additional information.

In the connection dialog box there is a 'Log' section. Please could you click on the + to expand that section, and then paste the all of information from there into the bug, after you've tried to authenticate using your certificate.

It might also be easier to try this from the terminal using 'openconnect' directly.

Hello David,
Here connection log


Attempting to connect to server 209.215.123.45:10443
Using client certificate '209.215.123.45'
SSL negotiation with 209.215.123.45
Server certificate verify failed: signature verification failed
Connected to HTTPS on 209.215.123.45
GET https://209.215.123.45:10443/
Got HTTP response: HTTP/1.0 302 Object Moved
SSL negotiation with 209.215.123.45
Server certificate verify failed: signature verification failed
Connected to HTTPS on 209.215.123.45
GET https://209.215.123.45:10443/+webvpn+/index.html
Please enter your username and password.
Certificate Validation Failure

> Attempting to connect to server 209.215.123.45:10443
> Using client certificate '209.215.123.45'
> ...
> Please enter your username and password.
> Certificate Validation Failure

OK, so you are attempting to authenticate yourself with a client certificate named "209.215.123.45", and the server does not seem to like that certificate.

I'm confused though; it looks like you're trying to authenticate to the server using its *own* certificate. Are you sure you're using the right certificate?

Can you connect with openconnect from the terminal, and show the '-c' and '-k' and '--cafile' options that you need to use to reproduce this?

There should 2 certs. One is establish https session and another for user authentication. And to me look like the order which cert in use is mixed, because
of this Using client certificate to establish session.

SSL works with a key *pair*. There is a private key, and a public key which is identified by (and contained in) the certificate.

To authenticate the https session, you only need the certificate. The private key is on the server — and *only* on the server. That's how it works. Anyone with the private key can pretend to be that server.

To use for client/user authentication, you need the cert *and* the private key (which may be stored in the same file). And openconnect checks that it's got a matching pair of cert and private key.

So it seems odd that you've have the *private* key for the VPN server on your client, but I suppose it's not impossible. It's certainly very odd that the cert you're trying to authenticate is named "209.215.123.45". I tried to connect to the server to see if *its* cert also has that same name, but it doesn't seem to be reachable.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.