Dynamic Access Policy (DAP) relationship with Self-signed Certificates

[ArielAR]

Currently, we have one of our NGFW configured for VPN use and able to connect to it successfully.  We are exploring the use of DAP for added control in who can connect to our VPN, so, we had configured some basic settings.  If we don't have it assigned and turned on for the existing working Remote Access VPN policy, all is well.  However, as soon as we assign/turn it on, when connecting via the VPN client, we get a message about the certificate that says... "untrusted server connection" in a red background (as far as what was initially described).  The self-signed cert is installed on the client side.  I am about to be part of the test group as well and will find out the exact error window that pops out.   With the above scenario, my initial question is that, what causes this to happen if we are actually not even using the certificate as a criteria in our DAP records?

[MHM Cisco World]

I dont fully understand get your Q

Can you more elaborate 

MHM

[ArielAR]

Good morning, MHM,
"How is the self-signed certificate deployed on each VPN client tied to the DAP configuration?"   We only picked two criteria in the DAP config at this time and did not use certificate criteria in the AAA of the record we created.  I just want to get a deeper understanding why enabling the DAP in the working RAVPN policy affect the behavior of the VPN connection, specifically, when the certificate criteria is not even being used.   If we un-assigned the DAP policy to the RAVPN policy, it works.  Thank you very much again for your guidance.  AR

[MHM Cisco World]

https://www.cisco.com/c/en/us/td/docs/security/secure-firewall/management-center/cluster/ftd_dap_usecases.html

There are many match conditions for DAP' do you use AAA ?

Check link to see how we can match conditions of AAA attributes

MHM

[ArielAR]

Hi, MHM,
Thank you for your email.
Here is the confirmed details of our environment.
We are currently using a valid self-signed certificate which is also installed in each of the VPN client system - it does not expire until 2031.
With DAP unassigned, our Remote Access VPN policy works good, and client experience is as expected - can connect with no extra steps to do.
With DAP assigned to the Remote Access VPN, when launching the VPN client, it first presents a message about the certificate being untrusted. Clicking "Connect" any allows us to proceed with the connection.
We are wondering why this is still being presented as such, when the self-signed certificate is still valid? Would a new certificate need to be recreated after the DAP is configured and have it redeployed to the client to get rid of the certificate message despite the current still being active?
We are trying to see if we can set it so it will not present such message, specially if the cert is still good.
Thank you in advance.

[MHM Cisco World]

Sorry for late reply' you use only cert. For auth anyconnect? 

MHM

[ArielAR]

Actually, we do have a self-signed certificate created under Objects > PKI > Certificate Enrollment - it is deployed client system.  Without DAP enable, the VPN connection goes smooth and presents just the normal dialog boxes associated to the connection - and successfully connects.   With DAP enable, regardless if there is only one endpoint criteria used (e.g. terminate connection if not running Windows 11), an extra dialog box associated to connecting to an untrusted server displays. If we select "Connect Anyway", it does a successful connection.   Just want to understand how the DAP is associated to the enrolled certificate as mentioned previously.   To re-iterate, we are also current not using the certificate as a criteria of the endpoint.    In addition, to add a bit more, during our investigation, we found that using the endpoint criteria seems to be a hit and miss, and that it also seems that it does not like to have more than one criteria in one record.  Right now, it is not making sense to me why...
Thanks so much again for your thoughts on this.

[Marvin Rhoads]

Is the certificate of your FTD headend also self-signed? I suspect when you use DAP there is an additional communication via client services that invokes the certificate via a separate "channel" than the usual login. I've always used CA-signed certificates with remote access VPN and in those cases DAP does not present any certificate errors.

[ArielAR]

Good morning, Marvin...Thank you so very much for your response. So far, that is the only certificate we are using for the FTD and is self-signed.  If we would like to keep it as such (self-signed) did you happen to stumble on a possible work around it so that it will behave like how if the cert as created from a CA?   Just wondering if there is a way to find that possible "channel"  and turn it off from there, per se :-).   Thanks so very much again - a cup of hot coffee for you and MHM. 

[Marvin Rhoads]

Sorry but a self-signed certificate will often present itself in undesirable ways. Why is there a desire to avoid using a proper certificate issued from either an internal or public CA?

[ArielAR]

Hi, Marvin,
Thank you for your response. Not actually a desire to avoid using CA cert but more on if we can get it working and have the VPN client recognize the self-signed certificate.

[MHM Cisco World]

Sorry for late reply 

Server - client 

Client use self signed certification of server to authc server 

But server I think dont use self signed certification 

Here is Key 

What server use to authc client '

I dont get clear reply 

MHM