[cisco-voip] CUCM DNS/CTL configuration - follow-up

Thu May 28 11:55:10 EDT 2015

Looks like I need to get my Tomcat certs signed before I can test this out
after all.. the CN for the tomcat and callmanager certs (self-signed) right
now on my cluster are the same and expressway won't setup the initial
connection.

The good news is I can get our internal CA to sign them which is the same
one that signed my expc cert and that I just uploaded, i just need to go
back and review the implications of doing this.. if I recall changing the
tomcat cert isn't a huge deal. I had just planned on waiting until we were
at cucm 10.x before I did that.

As Jason said, the CA cert did get replicated to the rest of the nodes in
the cluster automagically.

One odd thing I noticed after I uploaded it was that a
Cisco_Root_CA_2048.pem (another callmanger-trust cert) also took on the
certificate description that I gave the CA cert.

On Thu, May 28, 2015 at 11:10 AM, Jason Burns <burns.jason at gmail.com> wrote:

> Brian, since it's a trust cert you shouldn't need to upload it to every
> node. The certificate replication process I talked about previously in this
> thread handles putting the trust cert on all CUCM servers. Also - since
> it's a trust cert you're right - no resets of phones anywhere.
>
> Since this is a trust cert for CallManager to talk to an external party
> (specifically the SIP process) you will probably need to restart the CCM
> process before SIP TLS calls will complete between the VCS and CUCM. Certs
> need to be validated when the SIP TLS session is established, and this
> trust database in the CCM process is not dynamic as far as I know. It loads
> the trust certs on process start and that's it. Although - I might be wrong
> on this.. I've done SIP TLS to gateways and I don't remember if we always
> needed to restart CCM.
>
> Let us know if calls work without restarting CCM!
>
> On Thu, May 28, 2015 at 10:45 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>
>> I've seen it work most of the time just adding the CallManager-trust.  On
>> one occasion, I did have to restart the CallManager service for it to take
>> affect.  Make sure to upload to every node.
>>
>> You also shouldn't see any phone reboots for adding a CallManager-trust.
>> That would only be in the case you end up having to restart the CallManager
>> service.
>>
>> On Thu, May 28, 2015 at 10:37 AM, Ed Leatherman <ealeatherman at gmail.com>
>> wrote:
>>
>>> It's not a tomcat-trust cert though, the docs (and expressway) say it
>>> needs to go in the callmanager-trust
>>>
>>> On Thu, May 28, 2015 at 10:25 AM, Charles Goldsmith <
>>> wokka at justfamily.org> wrote:
>>>
>>>> Just restart Tomcat
>>>>
>>>> On Thu, May 28, 2015 at 8:21 AM, Ed Leatherman <ealeatherman at gmail.com>
>>>> wrote:
>>>>
>>>>> Good morning!
>>>>>
>>>>> Cert related question - think I know the answer but I dont see it
>>>>> explicitly stated so figured I'd ask.
>>>>>
>>>>> I need to add the CA cert for my expressway-C to call manager as a
>>>>> callmanager-trust cert - do I need to reboot the call manager service for
>>>>> this to take effect? No forced phone reboots since this is just a trust
>>>>> cert, correct? I think the answer is no and no phone reboots.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Ed
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Mon, May 18, 2015 at 10:46 AM, Brian Meade <bmeade90 at vt.edu> wrote:
>>>>>
>>>>>> Ed,
>>>>>>
>>>>>> All phones re-registering is expected behavior for when any
>>>>>> CallManager, CAPF, or TVS certificate on any node in the cluster is
>>>>>> regenerated.  This is to allow phones to download an updated ITL before
>>>>>> another certificate change is made.  This is also the same reason all
>>>>>> phones re-register when adding a new node to a cluster.
>>>>>>
>>>>>> Tomcat-trusts usually automatically get updated via the Certificate
>>>>>> Change Notification process.  There has been a few times I've seen
>>>>>> conflicts that caused this not to work right though.
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>> On Sun, May 17, 2015 at 10:06 AM, Ed Leatherman <
>>>>>> ealeatherman at gmail.com> wrote:
>>>>>>
>>>>>>> Good morning,
>>>>>>>
>>>>>>> This morning I enabled DNS servers, domain name on our CUCM Cluster,
>>>>>>> which involved regenerating all the certs on the cluster. Note I have
>>>>>>> cluster mixed mode. Everything appears to have gone smoothly, but I had 2
>>>>>>> odd things happen that I did not expect.. tossing them out here in case it
>>>>>>> helps someone else, or if someone has commentary on "why" :)
>>>>>>>
>>>>>>> Reference: CUCM v9.1, mixed mode, never had dns servers or domain
>>>>>>> set before.
>>>>>>>
>>>>>>> - After setting primary, secondary DNS and domain name, and the
>>>>>>> subsequent reboot on each node ALL my phones on the cluster restarted or at
>>>>>>> least re-registered each time, even for phones that do not use that node as
>>>>>>> a CM. Is this CM process restarting everywhere each time or ? I didnt think
>>>>>>> to check runtime on the CM process while I was working.
>>>>>>>
>>>>>>> - I expected to have to import tomcat certificates back and forth to
>>>>>>> the publisher at each node once the certs were regenerated, as this was
>>>>>>> necessary in the past. Apparently now they automagically download them from
>>>>>>> each other? I went in to do it and the tomcat-trust was already there with
>>>>>>> the new domain name.
>>>>>>>
>>>>>>> Cheers!
>>>>>>>
>>>>>>> Ed
>>>>>>>
>>>>>>> --
>>>>>>> Ed Leatherman
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cisco-voip mailing list
>>>>>>> cisco-voip at puck.nether.net
>>>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Ed Leatherman
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Ed Leatherman
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>

-- 
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150528/b13e7188/attachment.html>