cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3171
Views
0
Helpful
5
Replies

CUCM CTL certificates

jedellerby
Level 1
Level 1

Hi,

I'm trying to configure CTL and CAPF so I can use secure RTP in a CUCM7 system. The documentation is a little vague in areas so can anybody help woith the following queries:

1) Is there anyway I can avoid having to have 2 Cisco USB tokens to create the CTL file i.e. use third party certification?

2) If I use a Microsoft CA for the third party certificates, what template do I apply to the CSR request or does it not matter?

3) Which type of certificate do I import the certificate back into CUCM as, CAPF or CAPF-trust?

4) Do I need to import the root CA into CUCM somehow so it knows this is a trusted authority?

Thanks

Jed

1 Accepted Solution

Accepted Solutions

Jonathan Schulenberg
Hall of Fame
Hall of Fame
  1. No, you need at least two security tokens to sign the CTL. This is done on purpose in case you loose one as another poster found out a few months ago. If you loose both tokens, you must touch every phone manually to erase the CTL and LSC.
  2. I believe it needs to be the Subordinate Certificate Authority template. CAPF will generate certificates for the phones directly. It will not pass these signing requests back to the root CA.
  3. CAPF
  4. Yes, the root CA certificate must be imported into the CAPF-trust store before uploading the certificate from question three.

View solution in original post

5 Replies 5

Jonathan Schulenberg
Hall of Fame
Hall of Fame
  1. No, you need at least two security tokens to sign the CTL. This is done on purpose in case you loose one as another poster found out a few months ago. If you loose both tokens, you must touch every phone manually to erase the CTL and LSC.
  2. I believe it needs to be the Subordinate Certificate Authority template. CAPF will generate certificates for the phones directly. It will not pass these signing requests back to the root CA.
  3. CAPF
  4. Yes, the root CA certificate must be imported into the CAPF-trust store before uploading the certificate from question three.

Jonathan,

Thanks for the quick answer ... excellent response

  1. No, you need at least two security tokens to sign the CTL. This is done on purpose in case you loose one as another poster found out a few months ago. If you loose both tokens, you must touch every phone manually to erase the CTL and LSC.

Shame I can't hack around the two tokens as I only have one and this is just for a proof of concept peice of lab work, so it will be thrown away

   2. I believe it needs to be the Subordinate Certificate Authority template. CAPF will generate certificates for the phones directly. It will not pass these signing requests back to the root CA.

I went for subord so at least I was on the right track there, if I can just get past my two token issue I may be able to see how the full process works!

   3. CAPF

For the CAPF or CAPF-trust, do you know what the difference is between the two types?

   4. Yes, the root CA certificate must be imported into the CAPF-trust store before uploading the certificate from question three.

Is the CAPF-trust the CA root certificate? Is it the same for all the otehr -trust certifcates, you can have different CAs for each type of certificate? If not, I don't see how you upload the CA root certificate,

Thanks

Jed

  1. How did you manage to order only one? I thought that there is a restriction which requires quantity two be ordered. At a minimum I know that DCT throws a warning telling you to order two.
  2. CAPF is the certificate the CAPF service uses to sign/issue certificates. CAPF-trust is what the CAPF service trusts for valid certificates. By default this also includes the Cisco Manufacturing CA I believe.
  3. Yes. The -trust is what that service recognizes as valid. The same goes with tomcat and tomcat-trust. The tomcat certificate is what tomcat uses and tomcat-trust is what it validates the certificate you give it with. Each service can have it's own CA depending on your environment.

This is a lab setup and a colleague thought the second one was just a spare, which to some extent it is ... but a mandatory one it seems. So, somewhere within the organisation there is a second one, I was just trying to work out a quick way forward.

So, it sounds like the certificate import is a two stage process if working with a thrird party CA instead of the default Cisco organisation.

1) Import CA root as CAPF-trust, and this will be my Microsoft CA root certificate

2) Import CAPF certificate, and this will be the CAPF certificate issued by my Microsoft CA

However, something doesn't quite add up about this though as I have tried the following and it fails:

1) Import the CA root certificate as CAPF-trust. This then lists ca-server.pem and ca-server.der as a CAPF-trust certificate name. I used 'ca-server' as the name for the Root Certificate, and my CA server is named 'ca-server'

2) Import the CAPF certificate I generated by my CA. I enter 'ca-server' as my Root Certificate and then try and upload the previously created CAPF certificate.

     - At this point I get an error saying Unable to read CA certificate

So, exactly what should I be entering in the root certificate field as I can't seem to get it to reference my CA certificate?

Thanks

Jed

What your describing seems correct at first glance based on the configuration checklist for importing certificates.

You may want to try specifying the root certificate as "ca-server.pem"  instead of just "ca-server" when importing. It's been a while since I have done this  and I don't remember which is correct.

After reviewing the thread the only thing that I'm not sure was stated clearly is that you needed to generate a CSR from Certificate Management and provide that CSR to the CA when signing. The CSR needs to be for the CAPF service.

Perhaps another person can chime in on this one. I don't have time to reproduce this in a lab right now.