Anyconnect Secure Mobility Client, Network Access Module, wired PEAP

[ngtransge]

Hello there,

I am testing AnyConnect Secure Mobility Client, Network Access Module as supplicant with PEAP authentication for wired network users. With default configuration it is working well.  With default configuration it is Trusting any Root CA certificates installed on the OS.  Do you know how to configure NAM that it will validate ACS certificate with specific Root CA Certificate ?

In Network Access Module profile editor it has two options about Certificates:

One is Certificate Trusted Authority which has two options by its self  first is too trust any Root CA certificate that is installed on OS, and second is to import Root CA certificate in Profile. Potentially Second option can help in my case, I can manually import Root CA certificates in each profile. But I think it will be hard to update Root CA certificates in future  in that way.

Second is Certificate Trusted Server Rules,  this option have matching capability by certificate Common Name.  For what can be used this option ?

[Tarik Admani]

Hi,

Here is the following guide that will shed some light on validating the server certificate:

http://www.cisco.com/en/US/docs/security/vpn_client/anyconnect/anyconnect30/administration/guide/ac04namconfig.html#wp1161278

One is Certificate Trusted Authority which has two  options by its self  first is too trust any Root CA certificate that is  installed on OS, and second is to import Root CA certificate in Profile.  Potentially Second option can help in my case, I can manually import  Root CA certificates in each profile. But I think it will be hard to  update Root CA certificates in future  in that way. Root Certificates take some time expire, but you are correct this can be a headache later on the down the road if the root certificate were to expire. However if you are using auto-enrollment then the certificate should renew in a seperate process (http://social.technet.microsoft.com/Forums/sr/winserverDS/thread/55aa1c43-15f3-453c-9223-25517b0584f0). If that isnt the case then you can use the second option you pointed out which you clearly defined.

Second is Certificate Trusted Server Rules,  this option have matching capability by certificate Common Name.  For what can be used this option? Every certificate has a common name (CN) of its identity, if you have a network that has multiple radius servers, you can enter in the CN of the certificates that are presented in the eap exchange.

Tarik Admani
*Please rate helpful posts*

[ngtransge]

Hello Tarik,

Can you clarify second option capability?

In Second option which is Certificate Trusted Server Rules. Witch Certificate is matches in this option, locally installed on OS certificates or Identity certificate which ACS/RADIUS sent?

[Tarik Admani]

The identity certificate authority (I havent used this option before) but it is outlined in the document:

"When the Validate Server Identity option is  configured for the EAP method, the Certificate panel is enabled to allow  you to configure validation rules for Certificate Server or Authority."

Thanks,

Tarik Admani
*Please rate helpful posts*

[ngtransge]

Hello,

If I have following CA certificate installed on OS certificate store that is attached here. How can I match this certificate in NAM ? What will be correct “Certificate Trusted Server Rules” rule pattern?

[Travis Hysuick]

Normally the way it works is that you set up your Enterprise Root CA, and then have it issue a certifcate for the AAA server (ie ACS, ISE, etc). You then install this certificate on the AAA server and (in an Active Directory environment) add the Root CA certificate to the client systems local certificate store. What that means is that any certificates (such as the one installed on the AAA server) that are presented to the client that are signed by the root are automatically trusted.

Server validation is an extra step in terms of proving the identity of the AAA server to the authenticating client. As such, when you build the policy in the NAM editor, it would look similar to the image below:

I like to use the CN (Common Name) as the match criteria and build my CA issuance policy to always include the FQDN in the certificate for identity purposes.

Hope this helps!

[ngtransge]

Hello Travis,

When you specify Include Root CA Certificate, and path which is C:/temp/certnew.cer, what does it exactly mean it will take certificate from C:/temp/certnew.cer on local computer on which I do profile for NAM and include this certificate in profile, or it will take certificate from C:/temp/certnew.cer, on supplicant computer where NAM is installed with provided profile ?

[Travis Hysuick · Accepted solution]

The screenshot I attached included the path to the exported Root CA certificate. All I did was export the Root CA certifcate to a file, and include that cert in the profile (this is manual CA provisioning through the Profile Editor directly).

If you have already added the Root CA certificate to the clients trusted certifcate store via a Group Policy Object, you can select the other option "Trust any Root CA installed on the OS", which will work just fine.

If you don't have a Root CA in-house to issue certifcates, and are relying on the ACS self-generated certificcate for management and EAP authentication purposes, you will need to include the locally generated certifcate from each appliance in order to have the client trust the CSACS appliance.