CAPF Certificate Signing

[mathew.lear]

Hello All,

This morning I am have signed my CAPF certificate with Root CA but I am unable to upload to CUCM as the Certificate Signing bit is not checked.

cap

Does anybody know how I can activate this option on my certificate template in windows 2012 R2, at the moment its greyed out and I am unable to check the box ?

Any help would be appreciated :)

Thanks,

Mathew

[mathew.lear]

I think I found it, it seems that the template needed is the "Subordinate Certification Authority".

[Dennis Mink]

thanks for the update Matt, maybe add a screenshot of how you did this for future reference

[mathew.lear · Accepted solution]

After testing I am able to succesfully sign CAPF and upload to call manager using this certificate template in Windows Server 2012 R2 :

Thanks for the help guys :)

[Jonathan Schulenberg]

If you’re able to share, what was the compelling reason to CA-sign CAPF?

There are ongoing discussions about future design enhancements to CAPF so I would like to cite real-world use cases. The only reason I have seen is for 802.1x certificate-based authentication to AAA/ISE but most customers prefer to install/trust the CAPF certificate on AAA/ISE instead.

[mathew.lear]

Hello Jonathan,

This is my ccnp lab (not production), I signed it because the option was there to sign it.

Is there an advantage to not having a CA signed CAPF ?

Regards,

Mat

[Jonathan Schulenberg]

Ok, lab is a different story. If there was a production _requirement_ I was eager to hear what it was.

Here is my "why not" answer, if this was production: On the topic of CUCM crypto-anything my advice is to not add complexity or deviate from the product default that Cisco tested unless you have to. Some of these features aren't used all that often; your chance of hitting a defect is not small. For example, phones can only store ITL/CTL files less than 64KB. The CA adds data/size to a certificate (e.g. the CA's public key signature, CRL/OCSP, etc.) when signing it.

There are other certificates (e.g. TVS or ITLrecovery) that shouldn't be CA-signed since there is never a benefit gained from doing so. Everything the CA adds to the cert can alter the way clients or the server itself handles it. For example, if it adds a CRL/OCSP URL, will clients query it? How will they react to a failure/timeout of that CRL/OCSP? I suspect the way physical phones, which themselves vary in code bases over the generations, will differ in some cases to soft clients such as Jabber. This is especially true when it comes to key/hash length/complexity.

Lastly, InfoSec may not like this from a governance perspective since CAPF lacks a certificate revocation mechanism and making it a subordinate CA extends the trust chain.

[mathew.lear]

Many thanks for your reply Jonathan, I will keep in mind your comments when working on prod environments and share your comments with my team :)