Trusted Network Detection Server

[rmfalconer]

We have an automatic VPN policy that uses trusted network detection to determine when to have Anyconnect engage a VPN connection. The client profile has Anyconnect try to communicate with a server on a specific secure port. The certificate on the server is expiring and I'm curious what the best replacement method is.

The certificate hash is also defined in the profile xml, which is where my concern is. How is this hash created? If the new certificate has the same common name and SAN entries, will the hash match? If not, how does the hash get updated so that it matches with the new certificate?

Thanks.

[Udupi Krishna.]

The hash value is the certificate's thumbprint found on the trusted server. In case the certificate is changed on the server, the hash value changes.

You will need to manually add the new hash value into the anyconnect XML profile and push either via something like GPO or via firewall.

Once a profile change is made and updated on the firewall when any user connects, the new profile from the firewall is pushed to those machines.

[rmfalconer]

Couple of follow-ups.

The hash value shown in the xml doesn't match the thumbprint of the certificate. Is there some calculation it does that masks the true thumbprint?

What is the impact to currently connected clients? How often is Anyconnect checking for a trusted network? Is it only if there's a state change or is there a periodic check?

[Udupi Krishna.]

That's definitely weird because XML is a plain text file and hash isn't masked by the firewall nor at the end user machine once updated.

The hash verification is done during the initial connection to the firewall and there are no period checks made unless the state changes.

If the certificate expires and hasn't been changed on the servers, users will still be able to connect because the certificate hash is still the same.

If the certificate is changed and isn't known to end user's machine it will be detected as untrusted network, however if the profile is updated on the firewall, it would be pushed when connected and the next time the user reconnects and new hash matches, it would detect the network as trusted.

[rmfalconer]

Did some additional checks and the hash is 24 characters longer than the thumbprint. I also created a new certificate with the same CN and SAN entries and the hash is different. Looks like it's taking the thumbprint and combining with other info to get the hash. Maybe the port number since I did change that for the second certificate binding.

[Udupi Krishna.]

I think I know whats happening here. Review the "thumbprint algorithm" field of the certificate and check if its SHA1, thats probably why you would be seeing the differences.

Secure trusted network detection requires and works with SHA256 only. However it doesn't matter what algorithm the certificate itself uses.

For e.g. I ran a quick test in my lab and I see it pulled a SHA256 value (refer to image "profileeditor") and when I look at the certificate properties its using SHA1 as the thumbprint algorithm (refer to image "cert").

Now the next obvious question is how to determine a SHA256 value, you can use openssl and run the following command.

openssl x509 -noout -fingerprint -sha256 -inform der -in <certificate name>

So in my case,

openssl x509 -noout -fingerprint -sha256 -inform der -in test.cer

SHA256 Fingerprint=F5:D7:17:1F:51:50:BC:1D:44:EC:FD:AA:8F:58:CF:9E:CF:30:D7:14:64:EF:9D:34:7F:5F:BA:BB:B8:84:49:58 - matches profile editor

openssl x509 -noout -fingerprint -sha1 -inform der -in test.cer 

SHA1 Fingerprint=19:A1:8C:BF:F9:92:F7:76:49:1E:30:D4:4A:3E:B1:E1:A0:CE:CA:CF - Verification to ensure SHA1 matches