[cisco-voip] CUCM 11 and Jabber certificates

NateCCIE . nateccie at gmail.com
Tue Mar 29 14:47:59 EDT 2016


Anthony,
It seems by brevity in emails continues to cause confusion.

You are correct.  Restarting TFTP is still needed when uploading new
files.  What I am saying is the new port 6972 for HTTPS delivery of TFTP
files does not pickup the new certificate uploaded for tomcat until the
service is deactivated and reactivated or the server is rebooted.

I have the process down for getting rid of jabber certificate errors down
pretty good, but this threw me for a loop, since 6972 is new and restarting
services did not help.

Thanks,
-Nate

On Tue, Mar 29, 2016 at 11:34 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> Thank you for the heads up Nate.
>
> To clarify the topic of uploading TFTP files and restarting the TFTP
> service: It's only necessary to restart TFTP when initially uploading a
> file to TFTP, and not for subsequent uploads of existing files (I.e.,
> pushing changes to XML files).
>
> As a test, I just uploaded a brand new Group Configuration file to TFTP
> that had never been in there before.  Neither 6970 (HTTP) or 6972 (HTTPS)
> served up the configuration file, as expected.  I then restarted the TFTP
> service, then both 6970 and 6972 served up the file, as expected.  I then
> modified the XML file slightly, re-uploaded to TFTP, *did not* restart
> TFTP, and both 6970 and 6972 served up the modified file.
>
> At no time did I deactivate/reactivate TFTP in my testing, and I should
> also note that I already had (from way long ago) a third party Tomcat cert
> installed.
>
> I am running CUCM 11.0.1.20000-2, which is listed as a problem child in
> the defect given.
>
> Whether or not the Tomcat third party cert VS self-signed cert issue
> happens intermittently or all the time, I cannot say.  I saw my third party
> cert being presented in my testing of port 6972 (HTTPS).  From my
> interpretation of the defect given, it sounds like this is an intermittent
> issue which only affects newly uploaded third party certs, and will require
> you to restart TFTP as well as Tomcat.  And in some instances, restarting
> the Tomcat+TFTP services will not resolve the cert issue for port 6972
> (HTTPS), so you must deactivate TFTP all together, and reactivate it (or
> better yet, just reboot the whole server).
>
> I just wanted to add some commentary to the discussion, because I know
> that when I first read the OP email, it almost sounded like you have
> deactivate/reactivate TFTP every time you make a change to TFTP, so that
> port 6972 picks up the changes.  I think I was making the wrong assumption
> about the wording, but if I were to guess, other people reading it would
> draw a similar conclusion as well.
>
> On Tue, Mar 29, 2016 at 9:12 AM, NateCCIE <nateccie at gmail.com> wrote:
>
>> All,
>>
>>
>>
>> So CUCM 11 adds https download of TFTP files over port 6972, and jabber
>> wants to validate that cert.
>>
>>
>>
>> The good news is it uses the CUCM tomcat cert.  The bad news is
>> restarting TFTP and/or Tomcat do not restart port 6972.
>>
>>
>>
>> There is a defect about this CSCuy12120, you get to deactivate TFTP and
>> reactivate TFTP to get this to clear up, or reboot the node.
>>
>>
>>
>>
>>
>> Thanks
>>
>> -Nate
>>
>>
>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160329/0f498a34/attachment.html>


More information about the cisco-voip mailing list