Background
In configuring Cisco IP phones for use with 802.1x (dot1x) it is sometimes required that the phone's certificate (identity certificate) be loaded onto the RADIUS server to allow authentication. Cisco IP phones often have a Manufactoring Installed Certificate (MIC) or Locally Significant Certificate (LSC) or both installed for use with security features. The procedure for retreiving both the MIC and LSC from the phone are the same.
Verify What Certificates Are Installed On The Phone
To check which certificates are installed on the phone navigate through the phone's menu by pressing the Settings button and going to Security Configuration. From this menu it will display the status of the MIC and LSC. In the below case both the MIC and LSC certificates are installed.
All phones as of 79x1 and newer (including 69XX/89XX/99XX) come with a MIC installed from the factory. LSCs must be manually installed on the phones by following the Communications Manager Security Guide section found here http://tools.cisco.com/squish/A5E5A.
Retreive The Certificates From The Phone
Go to the Cisco Unified Communications Manager (CUCM) Administration web page and navigate to Device > Phone. Find and select the phone which the certificates are going to be retreived from. Navigate to the "Certification Authority Proxy Function (CAPF) Information" section of the phone configuration page and set the CAPF Operation to "Troubleshoot".
Click save and reset the phone. After the phone has reset and registers again, refresh the device configuration page to make sure the CAPF operation has completed. This can be identified by checking that the CAPF operation has changed automatically back to "No Operation Pending" and the Certificate Operation Status displays "Troubleshoot Success".
The certificates have to be downloaded from the CUCM publisher using the command line. The Real Time Monitoring Tool (RTMT) will not collect the certifiates. To view the available certificates use the following command.
admin:file list activelog /cm/trace/capf/sdi
SEP64A0E7157C51-L1.cer SEP64A0E7157C51-M1.cer
capf00000001.txt capf00000002.txt
capf~num.bin
dir count = 0, file count = 7
Use the following command to download all of the certificates. The exact file name can be specified rather than SEP*.cer to download only certain files. A Secure File Transport Protocol (SFTP) server is required to save the files to.
admin:file get activelog /cm/trace/capf/sdi/SEP*.cer
Since the phone had both a MIC and LSC installed there are two certificates. The certificates have their attributes.
| Type | File Name | Common Name (CN) | Issuer | Root |
|---|---|---|---|---|
| MIC | SEP64A0E7157C51-M1.cer | CN:CP-7965G-SEP64A0E7157C51 | Cisco Manufactoring CA | Cisco Root CA 2048 |
| LSC | SEP64A0E7157C51-L1.cer | CN:SEP64A0E7157C51 | CUCM's CAPF Certificate | CUCM's CAPF Certificate |
Troubleshooting
Sometimes the CAPF operation will not complete. Rather than seeing the CAPF operation status showing successful and the CAPF operation changing to "No Operation Pending" automatically that CAPF operation status remains as "operation pending" and the CAPF operation displaying the pending operation such as "Troubleshoot".
When the CAPF operation is not completing the first thing to check would be that the phone has the correct CTL and/or ITL files installed. The CTL and ITL files contain the CAPF certificate. This is how the phone authenticates the SSL/TLS handshake between CUCM's CAPF service and the phone to then perform the CAPF operation. The easiest way to make sure the phone has the correct CTL or ITL is to simply delete the current CTL and/or ITL file so that the phone downloads a new one when it is reset next.
Note: A phone with both a CTL and an ITL file installed will use the CTL file's CAPF entry to authenticate the SSL connection to CAPF.
Another way to verify if the CTL or ITL on the phone match between the CUCM and phone is to run the "show ctl" command from the CUCM TFTP's command line. Newer CUCM versions will display the MD5 of the CTL file in the output, while older CUCM versions do not.
admin:show ctl
The checksum value of the CTL file: cb1ae8ce60effb81a4316c34c8e37a43
If the "show ctl" output does not display the MD5 checksum (CSCto60209) download the CTLFile.tlv or ITLFile.tlv from the TFTP server and run an MD5 sum manually against the file.
joemar2$ tftp 14.48.46.2
tftp> get CTLFile.tlv
Received 4350 bytes in 0.1 seconds
tftp> quit
joemar2$ md5 CTLFile.tlv
MD5 (CTLFile.tlv) = cb1ae8ce60effb81a4316c34c8e37a43
The output of the MD5 can be matched against the display of the phone by pressing the Settings button and going to Security Configuration > Trust List.
In this case both the values match so the phone has the correct CTL file installed. If these values do not match, the CTL or ITL file would have to be manually deleted from the phone by entering **# to unlock the settings configuration followed by selecting the CTL or ITL file, selecting the unlock softkey, followed by the more softkey, and finally the erase softkey.
If the CAPF operation is still not completing even though the CTL/ITL file on the phone matches that of CUCM the next step is to take a packet capture from the phone. First enable "SPAN to PC port" on the device configuration page on CUCM and reset the phone. Take a packet capture from behind the phone while the phone is resetting and registers to CUCM. Filter the packet capture using "tcp.port==3804" to view CAPF traffic. Select a packet from the filtered list and decode it as SSL. One of the SSL messages will contain a certificate. View the certificate to make sure that the serial number in the packet capture matches the output of "show ctl" (or "show itl" if the phone only has an ITL).
The serial number for the certificate can be matched up to the CLI output by looking at the packet bytes while selecting the serialNumber field. The packet bytes show 22 11 3b fb f9 05 aa 0f which match the "show ctl" output below of 22:11:EB:FB:F9:05:AA:0F.
admin:show ctl
Length of CTL file: 4350
The CTL File was last modified on Thu Oct 13 15:06:46 EDT 2011
Parse CTL File
----------------
<SNIP>
</SNIP>
CTL Record #:4
----
BYTEPOS TAG LENGTH VALUE
------- --- ------ -----
1 RECORDLENGTH 2 942
2 DNSNAME 11 14.48.46.2
3 SUBJECTNAME 49 CN=CAPF-48c59125;OU=TAC;O=cisco;L=RTP;ST=NC;C=US
4 FUNCTION 2 CAPF
5 ISSUERNAME 49 CN=CAPF-48c59125;OU=TAC;O=cisco;L=RTP;ST=NC;C=US
6 SERIALNUMBER 8 22:11:3B:FB:F9:05:AA:0F
7 PUBLICKEY 140
9 CERTIFICATE 650 52 25 53 D5 7D 88 1B 16 67 3F 62 C8 72 10 7B EE D9 70 C1 09 (SHA1 Hash HEX)
10 IPADDRESS 4
The CTL file was verified successfully.
If the serial number for the CAPF certificate presented in the packet capture does not match the output of the show CTL/ITL, it is likely that the CAPF certificate has been modified since the CTL or ITL file was last updated. Check the "not valid before" date on the CAPF.pem certificate from the OS Administration web page or from the packet capture to make sure the CTL/ITL file has been modified at a later date. The last modified date of the CTL/ITL can be seen from the "show ctl" or "show itl" output from the command line. If the CAPF certificate was modified more recently than the CTL, the CTL client will have to be run to update the CTL file. This will put the new CAPF certificate into the CTL file which the phone will download when it is next reset.