Security Warning: Untrusted Server Certificate!" AnyConn-ISE Posture

[laurathaqi]

Dear community, 

I have detached and made this question alone, as am still stugling with the following issue: 

"Security Warning: Untrusted Server Certificate!" AnyConnect cannot verify server: ise1"

Certificate does not match the server name. 

Certificate is not identified for this purpose. 

Please see image attached.

I did research in regards this and the I also tested them but did not fix the issue are: 

1. ISE Certificate was generated as a Subordinate certificate and was signed from the Internal root CA. Root CA is imported in All network hosts. It is also selected and this is how we achieve the EAP-TLS authentication successfully. 

2. I've unchecked the "Block connections to untrusted servers", still not working. 

3. User am testing with does have local admin rights on the computer.

4. The client provisioning has the same certificate as the ones ISE does in the web browser. 

5. The ISE certificate SAN has the same FQDN of ISE. 

6. SAN of certificate has FQDN of ISE1 and FQDN of ISE2. But does not have IP addresses on it. 

7. CN of the certificate has also the same FQDN as ISE1, that FQDN that the host is reporting as unsecure.

8. AnyConnect configuration has home call list: FQDN of ISE1

9. Tried to import ISE1 Subordinate certificate in Certificate Trusted Authority in the Host, but I still faced the same error! Here, am not sure if I should import this as part of the process. 

Information: AnyConnect-win-webdeploy version: 4.10.xx

Any idea how I can further troubleshoot on eliminating this popup of untrusted server! 

Note: during the process, this process shows up once, and the user needs to click connect once.

The popup shows at the moment when the module starts to scan, at 1%. 

Took the Wireshark packet capture, and the certificate being presented is the correct one of ISE. 

I also tried to regenerate the certificate for portal only, by creating one that has as SAN the fqdn and ip address of the ISE. The portals of CPP and Admin do not show the untrusted certificate issue. When posture scanning starts at 1% am forced to click connect anyway and then that is it. The posture completes with success. 

Any idea how to further troubleshoot? Am out of ideas right now. 

Looking forward to hearing from you. 

Thank you,

Laura

[laurathaqi]

Dear community, 

Did someone hit on the following bug: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn81322 yet? 

My AnyConnect version is 4.x however, just been wondering if this might be still an issue! 

Also, not sure if I understand the Workaround correctly! Thus your point of view would be highly helpful. 

Looking forward to hearing from you.

Thank you,

Laura

[Mike.Cifelli · Accepted solution]

Are you able to share the enhanced key usage (EKUs) for the certificate in use? The "Certificate is not identified for this purpose" is making me wonder if the cert template used to generate the certificate is misconfigured.

Have you seen this: How To Implement Digital Certificates in ISE - Cisco Community

[laurathaqi]

Hi @Mike.Cifelli 

It has both Client and Server Authentication EKU's. However, during today call with TAC they recommended to have:

X509v3 Key Usage: Digital Signature, Non Repudiation, Key Encipherment, Key Agreement, Certificate Sign , meanwhile my cert is missing the Key Encipherment and Key Agreement.

Do you think this might be an issue, and or do you have any recommendation in regards this in terms of default best practice approaches?! 

Thank you,

Laura

[laurathaqi]

Hi @Mike.Cifelli, 

The internal CA templates would not allow us to place KU of Key Encipherment, Key Agreement in the Certificates. So we proceeded with Self Signed Certificate and we placed it to the Users Trusted Store, and the error went away. The Self Signed has the KU's noted. 

Thank you for you amazing support. 

Best wishes,

Laura

[Bernd Nies]

As the alert does not show the FQDN I suspect that the iseposture/ConnectionData.xml only contains the short name. Also check that the portal certificate is the correct one.

curl -v https://ise.example.com:8443
openssl s_client -connect ise.example.com:8443 | openssl x509 -text

We once had a similar issue on Mac where the posture complained about untrusted certificate, although everything was correct. Deleting the CA certificate on the client's keystore and adding it again fixed that issue.

Bye

Bernd