cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4790
Views
25
Helpful
9
Replies

Call Manager Certificates

gene.evans
Level 1
Level 1

What is the difference between regenerating a certificate and requesting a CSR?  The tomcat.pem and CallManager.pem are due and I would like to just regenerate them.  I am running 8.6.2000.  I just want to make sure that regenerating will not cause a problem and understand the difference.

4 Accepted Solutions

Accepted Solutions

Chris Deren
Hall of Fame
Hall of Fame

Are these self signed certs or certs signed by your CA?

Chris

Sent from Cisco Technical Support iPhone App

View solution in original post

Gordon Ross
Level 9
Level 9

If you regenerate a certificate, CUCM will sign the certificate itself.

If you generate a CSR, then some other CA has to sign the CSR to turn it into a certificate.

Getting CUCM to self-sign is less work: But does result in various browser warnings about untrusted certificates.

Using a CA, you avoid browser warnings.

Note, that you don't have to use a commercial CA to sign these certificates. You can run your own CA (and import that certificate into your browsers, etc).

Setting up your own CA isn't too hard, and does make things neater in the long run.

GTG

Please rate all helpful posts.

Please rate all helpful posts.

View solution in original post

To add to the concern about not causing problems, if you are regenerating certificates on CUCM 8.6(2) regenerating the tomcat certificate and/or CallManager certificate will cause all of your phones to reset immediately.  This is a safely precaution to void issues with the Initial Trust List (ITL) on the phones not being updated.  When regenerating certificates be sure to regenerate one at a time, and allow the phones to reset in between before regenerating the next certificate.  For example on your publisher if you regenerate the call manager certificate, wait for the phones to reset and register back before clicking the regenerate button for the tomcat certificate.  Once the phones are back up and registered, you can regenerate the tomcat certificate and again wait for the phones to register back.  Then you can do the same on the rest of your nodes again only regenerating one certificate at a time.  This will help prevent a loss of trust between the phone and the CUCM servers.

Here's some more information about the correct process for regenerating certificates and things to be aware of,

https://supportforums.cisco.com/docs/DOC-17679#Regenerating_Certificates__Rebuilding_a_Cluster__Certificate_Expiry.

View solution in original post

I'm not so sure about the Tomcat cert causing phones to reboot.

By co-incidence, I updated the Tomcat cert on all the servers in my cluster this morning: Not a single phone reboot. (This is on a 9.1 cluster)

Back when I was on 8.6.something, there was one cert which, when I regenerated, caused every phone in the cluster to reboot. Can't remember which cert that was, unfortunately :-(

GTG

Please rate all helpful posts.

View solution in original post

9 Replies 9

Chris Deren
Hall of Fame
Hall of Fame

Are these self signed certs or certs signed by your CA?

Chris

Sent from Cisco Technical Support iPhone App

Gordon Ross
Level 9
Level 9

If you regenerate a certificate, CUCM will sign the certificate itself.

If you generate a CSR, then some other CA has to sign the CSR to turn it into a certificate.

Getting CUCM to self-sign is less work: But does result in various browser warnings about untrusted certificates.

Using a CA, you avoid browser warnings.

Note, that you don't have to use a commercial CA to sign these certificates. You can run your own CA (and import that certificate into your browsers, etc).

Setting up your own CA isn't too hard, and does make things neater in the long run.

GTG

Please rate all helpful posts.

Please rate all helpful posts.

To add to the concern about not causing problems, if you are regenerating certificates on CUCM 8.6(2) regenerating the tomcat certificate and/or CallManager certificate will cause all of your phones to reset immediately.  This is a safely precaution to void issues with the Initial Trust List (ITL) on the phones not being updated.  When regenerating certificates be sure to regenerate one at a time, and allow the phones to reset in between before regenerating the next certificate.  For example on your publisher if you regenerate the call manager certificate, wait for the phones to reset and register back before clicking the regenerate button for the tomcat certificate.  Once the phones are back up and registered, you can regenerate the tomcat certificate and again wait for the phones to register back.  Then you can do the same on the rest of your nodes again only regenerating one certificate at a time.  This will help prevent a loss of trust between the phone and the CUCM servers.

Here's some more information about the correct process for regenerating certificates and things to be aware of,

https://supportforums.cisco.com/docs/DOC-17679#Regenerating_Certificates__Rebuilding_a_Cluster__Certificate_Expiry.

I'm not so sure about the Tomcat cert causing phones to reboot.

By co-incidence, I updated the Tomcat cert on all the servers in my cluster this morning: Not a single phone reboot. (This is on a 9.1 cluster)

Back when I was on 8.6.something, there was one cert which, when I regenerated, caused every phone in the cluster to reboot. Can't remember which cert that was, unfortunately :-(

GTG

Please rate all helpful posts.

You're right!  It's the TVS certificate not the tomcat certificate.  This is documented by https://tools.cisco.com/bugsearch/bug/CSCue55353/.  Regenerating the following certificates cause the phones to reset TVS/CCM/CAPF.

Gordon,

 

So I will ALWAYS see the "site not trusted" if it's self signed UNLESS I use a 3rd party cert or host a CA and import to our browsers, correct?  It's my browser trying to authenticate the cert with a 3rd party who has no idea what it is and therefor shows it as "unsafe", correct?  

 

Question:  If we get a 3rd party cert, what kind is needed (wildcard, etc.) and which tomcat cert is it needed on to remove the web login errors?

 

Thanks,

 

Jon

gene.evans
Level 1
Level 1

This is great information. I have two main certs that I will regenerate.  The Tomcat.Pem and CallManager.PEM, this will update the trust certs for the Node.  From what I am reading it is ok to regenerate the Tomcat.PEM and The CallManager.PEM to make them self signed.  I am alos going to restart each server after the certificates for each have been updated.  On other clusters I have waited for each certificate to update and phones to reboot, this was a critical step.  I think I understand now, thanks everyone for your help.

The cert that causes the phones to reboot is CallManager.pem if any of the phones are using the cert from that node.  I found that out on my last cluster.  The call manager service also restarts as soon as the CallManager.pem is updates.

Right, the new certificate is not "in use" until the service the certificate belongs to  is restarted (example the callmanager.pem and the CallManager service).