[cisco-voip] IM&P - services reported in unknown state after SAN cert install

[Erick Wellnitz]

It was Go Daddy.

I uploaded the bundle they sent all at once to the tomcat-trust then the
individual multi-server cert to tomcat.  The root was missing from that
bundle.  Going out to their website and downloading the root, G2 root in
this case, and uploading it to tomcat-trust was all I needed to do.

Maybe the customer didn't provide me with the file containing the entire
chain but I remember vaguely this happening on previous jobs with Go Daddy.


On Thu, Mar 17, 2016 at 8:35 AM, Anthony Holloway <
avholloway+cisco-voip at gmail.com> wrote:

> Thanks for replying.  Did you use a public CA or private CA?  And did you
> upload all certs in the chain (sans the root) as one file, or as separate
> files?
>
> On Wed, Mar 16, 2016 at 8:06 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
> wrote:
>
>> The root CA cert wasn't uploaded.  The bundle the CA provided didn't
>> contain the root for whatever reason.  Once the root was in place and after
>> a tomcat restart everything started working properly.
>>
>> So, the whole thing was caused by not paying close enough attention to
>> what got added to romcat-trust after the cert bundle upload.
>> On Mar 16, 2016 4:35 PM, "Anthony Holloway" <
>> avholloway+cisco-voip at gmail.com> wrote:
>>
>>> What do you mean?  Was it simply not uploaded to the Tomcat Trust?  Or
>>> was the cert bad?
>>>
>>> On Mon, Mar 14, 2016 at 3:31 PM, Erick Wellnitz <ewellnitzvoip at gmail.com
>>> > wrote:
>>>
>>>> It was the root ca cert causing this.
>>>>
>>>> Thanks everyone for the input
>>>>
>>>> On Mon, Mar 14, 2016 at 1:44 PM, Ryan Huff <ryanhuff at outlook.com>
>>>> wrote:
>>>>
>>>>> Correct; tomcat-trust is the trust store where the trusted CA chain
>>>>> goes and then the server certificate goes in the tomcat category.
>>>>>
>>>>> Afterwards; you should only need a restart of tomcat services.
>>>>> However, if the nodes are having issues trusting one another within the
>>>>> cluster (assuming that your issue is a cert trust issue); left that way
>>>>> long enough will likely start to cause replication issues within the
>>>>> cluster.
>>>>>
>>>>> After you resolve the issue, I would verify db replication is healthy.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Mar 14, 2016, at 3:38 PM, Erick Wellnitz <ewellnitzvoip at gmail.com>
>>>>> wrote:
>>>>>
>>>>> I did that as well but I'm not 100% sure if the entire Root CA chain
>>>>> got installed.  I'll check that.
>>>>>
>>>>> What made me try inserting the multi-server SAN into the tomcat-trust
>>>>> is that the IM&P entries for tomcat-trust have vanished.  Maybe I'm
>>>>> mis-remembering seeing them there in the first place.
>>>>>
>>>>> On Mon, Mar 14, 2016 at 12:54 PM, Anthony Holloway <
>>>>> avholloway+cisco-voip at gmail.com> wrote:
>>>>>
>>>>>> Just to clarify, your Multi-Server SAN cert should be installed to
>>>>>> Tomcat and not Tomcat Trust.  The signing CA cert should go in Tomcat
>>>>>> Trust.  Is that what you meant to say you did?
>>>>>>
>>>>>> On Mon, Mar 14, 2016 at 1:47 PM, Erick Wellnitz <
>>>>>> ewellnitzvoip at gmail.com> wrote:
>>>>>>
>>>>>>> I have a strange issue with CUCM 11.0.1 and IM&P 11.0.1
>>>>>>>
>>>>>>> We installed the multi-server SAN cert for tomcat and now the IM&P
>>>>>>> data monitor service is in an unknown state according to the system
>>>>>>> troubleshooter.
>>>>>>>
>>>>>>> The SAN cert is installed to tomcat-trust so it shouldn't be a cert
>>>>>>> issue.  Done service restarts, reboots and nothing seems to resolve this.
>>>>>>>
>>>>>>> Anyone seen something like this before?
>>>>>>>
>>>>>>> Thanks in advance!
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20160317/6acd91c3/attachment.html>