Cisco ISE 2.3 dot1x authentication for Cisco IP Phones

[Jabroni1972]

We are preparing to deploy Cisco UC and IP phones throughout our environment.  I have read many articles on preparing ISE for the use of Cisco phones (CAPF cert from UC imported to ISE, new CAP profile etc).  The issue that I am running in to is we also use ISE for PC authentication as well (utilizing a machine cert located on the machine and a cross-check to AD for the username).  Anyway, no matter what I try when I power the phone up it attempts to use the authentication policy for our PCs (Cert_Auth_-_Machine) and not the new authentication policy I created for our phones (Cert_Auth_-_UC).  As such I receive a failure reason 22047 - User name attribute is missing in the client certificate.  I have created the Policy set to look for "CAPF" in the Issuer-Common Name for the certificate but am stuck at this step.  Any assistance would be greatly appreciated.

[paul]

Use the Issuer common name critieria in your authentication phase to call up your new CAP.  Make sure the authentication rule falls ahead of your other cert authentication rules.

[Colby LeMaire]

You don't necessarily need a different authentication policy rule or CAP for PC's and phones.  The CAP just says what field in the certificate should be used for the identity lookup.  If you are using Common Name (CN) for PC's and for phones, then you just need the one CAP and associated authentication policy rule.  And sometimes, you may need to use the SAN for PCs but using the SAN for phones would still work too.  Bottom line is if you can use the same common attribute in the certificate, then you don't need separate CAP's.

[paul · Accepted solution]

Most modern certificate best practices stipulate the common name means nothing and SAN fields should contain the relevant information.  I use SAN fields for all my customer setups, but in some cases if you are authenticating certificates installed onto devices they may not have the identity information correctly in the SAN field and you have to use another CAP for common name.

As Colby said if you can find a common area of the cert that contains identity for all certificate use cases (most likely SAN fields) you can use one CAP and do all the inspection in the authorization phase where it should be happening.