In this post I’m gonna show you the steps for authenticating your IP phones using 802.1x and certificates. I encourage you reading the “IP Telephony for 802.1X Design Guide” before for a better understanding.
Let’s start with some background on the different types of certificates and the role they play before getting into the configuration steps. Cisco IP Phones support two types of X.509 certificates: the Manufacturing Installed Certificate (MIC) and the Locally Significant Certificate (LSC). Customers typically leverage MICs and LSCs to secure the signaling and voice path used for IP telephony, but the same certificates can be used for 802.1X. As the name suggests, the MIC is pre-loaded on the phone at the time of manufacture. The Cisco Manufacturing Certificate Authority signs it.
A phone that presents a valid MIC can be assumed to be a valid Cisco phone. However, the MIC by itself cannot be used to determine whether this phone is a corporate asset or a rogue Cisco phone. For that, you need an LSC. Unlike the MIC, the LSC is signed by the CAPF of the Unified CM, which is the central call control and configuration engine for Cisco IP Telephony.
In an 802.1X authentication, the AAA server is responsible for validating the certificate provided by the phone. To do this, the AAA server must have a copy of the root CA certificate that signed the certificate of the phone. The root certificates for both LSCs and MICs can be exported from the Unified CM Operating System Administration interface and imported into your AAA server.
After the certificate has been validated, the AAA server may be able to authorize the phone simply based on attributes in the certificate. This is the recommended way to authorize phones with certificates, because it enables you to authenticate and authorize phones with a single global policy and avoids the need to enter individual phones in a database. Cisco ISE supports this type of authorization.
802.1X is not enabled by default. For scalability and ease of deployment, phones should be enabled for 802.1X via the network. It is possible to enable 802.1X on phones by enabling 802.1X in the phone configuration file or via the Bulk Administration Tool on the Unified CM. The next time the phone resets and downloads its configuration file, 802.1X is enabled for all supported EAP methods.
- Enable 802.1x on the phone set up in the CUCM and enable the feature:
- Create the CAPF at CUCM the services level and export the certificate:
- Add the certificate to the “Trusted Certificates” store in ISE:
Otherwise ISE would return an error because of the CA presented is not trusted as you can see in the image below:
- Configure a new CAP just for phones:
With the Certificate Authentication Profiles or CAPs you instruct ISE how to retrieve information from the certificates the supplicants send and whether or not match that information against some identity store. For the EAP-TLS authentication create a phone CAP. This CAP will look for the Common Name in the certificate for authentication.
- Create an individual identity sequence for phone:
Finally, create an individual identity sequence for phone only where you reference the Phones CAP just created. With identity source sequences you group the different users and endpoints repositories, whether they are internal to ISE or external. You also specify the CAP to use in order to retrieve the appropriate data from the certificates. Two different identity source sequences are necessary, one for phone authentication where the previous “Phone CAP” is selected to collect the Common Name from the certificate presented by the phone and one for the rest of the endpoints and users.
- Authentication Policy:
- Authentication Results: