TL;DR
Can the CallManager's CAPF sign Locally Significant Certificates (and include the certificate chain in the LSC)?
Background
Equipment
I have basic telephony set up in a lab environment I have access to at work (none of this is production). The purpose of all this is purely self-developmental. Here is the equipment I am using. The following services are virtualized on ESXI 6.5.
CallManager 11.5(1)SU4
IM and Presence 11.5(1)SU4
Prime License Manager 11.5(1)SU5 (just to enable encryption on the CUCM)
Windows Server 2016
Network Devices: 3750 w/ POE and IOS 15.0.2
Clients: 7945G IP Phone and Windows 10 Laptop running Jabber 12.5(1)
Current State
The IM&P database is synced with the CUCM and Jabber Softphones and 7945Gs are able to register and call each other with no issue. The CUCM is LDAP synchronized to the Windows Server 2016 Active Directory, and all users are associated to a working Jabber Softphone. The Windows Server Domain Controller is also running Certificate Authority Services and has signed and issued the appropriate certificates to the CUCM (CallManager, tomcat, and CAPF) as well as being added as a trusted root CA for those services. Then I updated the CTL and reset all IP Phones:
admin:utils ctl update CTLFile
I wanted to enable SRTP and secure the communications from end-device to end-device so I enabled mixed mode using:
admin:utils ctl set-cluster mixed-mode
I then used the CAPF to issue LSCs to the end devices and configured a secure phone profile.
The following images show a that a softphone and 7945G were able to establish a secure channel (lock icon).
Super! Everything is working great, and I'm learning a ton. But...
The Next Step
My original configuration for the 3750s was to authenticate attached devices with 802.1x. Windows NPS is the acting RADIUS server and workstations/users are authenticated with auto-enrolled certificates over EAP-TLS. These devices (Windows laptops) authenticate over 802.1x without a hitch and the certificate exchange has been observed through wireshark on a SPANed port on the 3750. The problem I'm running into now is that the LSC issued by the CAPF to the 7945 is unsigned and does not have the attributes to support a certificate chain. Without the chain, Windows NPS does not trust the certificate received on EAP-TLS and rejects network access.
View from the 3750's console:
Here is the LSC I retrieved from the CUCM:
As you can see, it lacks the attributes supporting a certificate chain, which is why NPS doesn't see its own CA and therefore rejects it.
To work around this, I used the following guide to sign the LSC as a "Third-Party." Third-Party CA-Signed LSCs
Here is the LSC now after being signed by the CA, and with the right attributes to retrieve the chain:
Now the 7945G authenticates successfully:
While this "works," the solution is hardly scaleable. It was a tedious process moving the certificate around from CUCM Web to CUCM CLI to TFTP server to CA, then back to TFTP and then to CUCM CLI then finally to the phone again. Ideally, I see the CAPF acting a subordinate CA, issuing and signing certificates to its user and devices registered on the CUCM. That was the reason I followed this guide to sign the CAPF certificate with my CA: CA-Signed CAPF.
Viewed in the CA Services panel
Here is the CAPF certificate downloaded from the CUCM
If the CAPF is a signed subordinate certificate authority, could it not create a certificate chain for all of the certificate it issues to devices? What was the point in signing my CAPF certificate if it doesn't sign any certificates itself? Is there a configuration in the CUCM that would allow for this functionality? Am I missing the point of the CAPF? I recognize that using ACS or ISE would alleviate this EAP-TLS issue with Windows NPS, but is there a simpler solution than migrating all my AAA to a new service?
Thanks in advance. There may not be an easy fix for my use-case, but I'm looking forward to any insightful discussion.
-Sebastien
Accepted Solutions
Oook I find out what was the issue, with the help of a killer Windows CA administrator.
It is clearly not mentionned on Cisco documentation.
When CAPF logs shows the error Enrollment rv = 22 (EST_ERR_AUTH_FAIL) with pkcs7 length = 0, this is a template issue.
Test the service account on the webpage of the CA server (http://<CA IP>/certsrv), try to generate a new certificate and you must see the template.
If not, most of the time Tac will point permission issue, but that's wrong here.
In fact the CES service on the CUCM, that perform the cert enrollment, is acting exactly as the same way as it is browsing the web page of the CA. This info is in the troubleshooting documentation:
However, what it's not said, it is the certificate template version.
In fact the CA web page only displays the template in version 2003, not the template in version 2008. The web page certificate enrollement on windws CA is the "old" way to do, so not that much developped (normally certs are now issued using the mmc console with rpc).
That's means the template to be used must be in version 2003 on the Windows CA.
But with this, that may not work for another reason: the template name.
In fact a template on WIndows CA has:
- A Template Name
- A Template Display Name.
These 2 names must match, otherwise it will fails.
Only with these requirements, it will work, and cert will enrolled imemdiatelly.
I was able to cross test almost all the scenario, and it was the only one working.
Hope that helps!
