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

[Horton, Jamin]

I've always had to add it as a SAN

Sent from my iPhone forgive any typos

On Mar 17, 2016, at 6:19 PM, Erick Wellnitz <ewellnitzvoip at gmail.com<mailto:ewellnitzvoip at gmail.com>> wrote:


Not to beat a dead horse but how does everyone typically handle the www.<fqdn> that GoDaddy likes to insert into the cert as an alternate name?  Is it okay to ignore that or should it be added as a domain when creating the CSR?

On Mar 17, 2016 1:25 PM, "Kevin Przybylowski" <kevinp at advancedtsg.com<mailto:kevinp at advancedtsg.com>> wrote:
My typical process with Godaddy is to open the cert – manually copy the root and intermediate certs to a file.  Then upload the root, followed by inter certs as tomcat-trust, then upload the tomcat cert itself.  It’s been pretty successful with that process…  The certs on UC can be fun.



From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net>] On Behalf Of Ryan Huff
Sent: Thursday, March 17, 2016 3:19 PM
To: Erick Wellnitz <ewellnitzvoip at gmail.com<mailto:ewellnitzvoip at gmail.com>>
Cc: Cisco VoIP Group <cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>>
Subject: Re: [cisco-voip] IM&P - services reported in unknown state after SAN cert install

As much as I hate to plug for MS Windows; you can typically use the Windows certificate viewer to extract each CA in a bundle (speaking from Godaddy experience myself). However the penguin (Linux) can do it faster IMO, but not always as intuitive.

Sent from my iPad

On Mar 17, 2016, at 3:15 PM, Erick Wellnitz <ewellnitzvoip at gmail.com<mailto:ewellnitzvoip at gmail.com>> wrote:
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<mailto: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<mailto: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<mailto:avholloway%2Bcisco-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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip


_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip





_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto: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/20160318/4cc4411c/attachment.html>