Re: [cisco-voip] Cisco Webex Serviceability Connector

[Anthony Holloway]

Never heard of it.  Looks like we're all learning something new from the
list today.  Thanks for sharing.

On Wed, Jun 3, 2020 at 7:54 PM Tim Smith  wrote:

> Hi guys,
>
> Crossposting here possibly for some of you.
> This tool is truly awesome. IMHO - If we all get on board, this will
> definitely help drastically decrease time to resolve TAC cases.
> I'm sure that will benefit us all!
>
> This works to collect pretty much everything TAC needs - i.e. you can
> shelve your RTMT collection process 🙂
> Oh, it works with CUBE too!
>
> Also, don't know if anyone is using TAC bot yet either, but I'm loving
> that too.
>
>
> See below:
>
> If you are a hybrid Cisco UC customer with Webex Control Hub and
> On-Premise UC (CUCM, IMP, Expressway etc).
> Here is an amazing piece of kit that is currently flying a little under
> the radar.
>
> Meet the Cisco Webex Serviceability Connector!
> Deploy the serviceability connector on an on-premise Expressway. Then
> connect it to your on-premise CUCM, IMP, UCCX, Expressways.
>
> Add the Connector in your Control Hub, and now Cisco TAC will be able to
> interrogate your on-premise UC apps for diagnostics. (Including running
> debugs through the Collaboration Solutions Analyser - looking for common
> issues)
>
> https://lnkd.in/g6caifH
>
> Cheers,
>
> Tim
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] vCUBE Experiences

[Anthony Holloway]

Was that trunk to Twilio for CME?  If not, what was on the backside of your
gateway?  CUCM?  If so, was that in AWS too?

On Wed, Jun 3, 2020 at 6:54 PM Tim Smith  wrote:

> Great question, also interested in hearing production stories.
>
> I've deployed Virtual Acme Packet's previously - same limitations - no
> DSP's etc.
> It was a little early and we had teething issues of appliance to virtual
> machine type stuff.. but through the updates this improved.
>
> I've played with CUBE on CSR1000V on AWS - SIP trunks to Twilio - and it
> works great.
> It's certainly so nice and easy to spin up.
> I've also run CSR1000V in AWS for dynamic VPN's.. which again works great.
>
> The DSP's are a nice fallback. You don't need them 99% of the time.. but
> when that 1% case comes up later - then it's certainly handy.
> I think that's a big reason vCUBE is not quoted in customer land.
> I assume it could be popular in service provider land though.
>
> With that Acme deployment (and this was actually years ago now) - we were
> migrating, so we still had PRI gateways with plenty of free DSP's, which we
> could use for Transcoders if required.
>
> Cheers,
>
> Tim.
>
>
>
>
>
> --
> *From:* cisco-voip  on behalf of
> Anthony Holloway 
> *Sent:* Thursday, 4 June 2020 7:06 AM
> *To:* Cisco VoIP Group 
> *Subject:* [cisco-voip] vCUBE Experiences
>
>
> EXTERNAL SENDER WARNING. This message was sent from outside your
> organisation. Please do not click links or open attachments unless you
> recognise the source of this email and know the content is safe.
> Anyone have some vCUBEs out in production for a while, and willing to
> share their feelings and/or experiences with it?
>
> Anything from deployment, to restrictions, to licensing, to upgrade
> processes, lessons learned, etc?
>
> I think the obvious thing is the lack of DSP/PVDM since this is a virtual
> machine, but what else?
>
> I don't come across these in the field at all, and I don't see them being
> proposed or quoted these days, despite vCUBE having been around for a few
> years now.
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Third Party CDR Analysis

[Brian Meade]

Variphy seems to be my favorite so far.  I like it much better than the ISI
offering.

On Wed, Jun 3, 2020 at 4:25 PM UC Penguin  wrote:

> I’m curious what third party CDR Analysis software is commonly used today
> and pros/cons of each?
>
> Looking for something friendly for non-Engineers to run reports.
>
> Thanks in advance
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] vCUBE Experiences

[Anthony Holloway]

What versions are you using/seeing out there?  Any 17 code?

I noticed that when you download the OVA you pick an IOS version.  How does
that affect upgrades?  Do you upgrade like an ISR, or do you do something
else?

On Wed, Jun 3, 2020 at 6:38 PM Erick Bergquist  wrote:

> Been using for awhile now without issue. Typical setup (bunch of dial
> peers, server groups, e164 pattern maps, etc).
>
> The only problem was a tcl script media playback issue in earlier ios
> version which we worked through with TAC and bug fixed in newer ios
> versions for awhile now.
>
>
> On Wed, Jun 3, 2020 at 4:30 PM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Anyone have some vCUBEs out in production for a while, and willing to
>> share their feelings and/or experiences with it?
>>
>> Anything from deployment, to restrictions, to licensing, to upgrade
>> processes, lessons learned, etc?
>>
>> I think the obvious thing is the lack of DSP/PVDM since this is a virtual
>> machine, but what else?
>>
>> I don't come across these in the field at all, and I don't see them being
>> proposed or quoted these days, despite vCUBE having been around for a few
>> years now.
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Cisco Webex Serviceability Connector

[Tim Smith]

Hi guys,

Crossposting here possibly for some of you.
This tool is truly awesome. IMHO - If we all get on board, this will definitely 
help drastically decrease time to resolve TAC cases.
I'm sure that will benefit us all!

This works to collect pretty much everything TAC needs - i.e. you can shelve 
your RTMT collection process 🙂
Oh, it works with CUBE too!

Also, don't know if anyone is using TAC bot yet either, but I'm loving that too.


See below:

If you are a hybrid Cisco UC customer with Webex Control Hub and On-Premise UC 
(CUCM, IMP, Expressway etc).
Here is an amazing piece of kit that is currently flying a little under the 
radar.

Meet the Cisco Webex Serviceability Connector!
Deploy the serviceability connector on an on-premise Expressway. Then connect 
it to your on-premise CUCM, IMP, UCCX, Expressways.

Add the Connector in your Control Hub, and now Cisco TAC will be able to 
interrogate your on-premise UC apps for diagnostics. (Including running debugs 
through the Collaboration Solutions Analyser - looking for common issues)

https://lnkd.in/g6caifH

Cheers,

Tim
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] 8800 Cloud vs On Premise feature comparison

[Jason Aarons]

Looking for the 8845/65 comparison of WebEx registered multiplatform
features vs on-premise?

Anyone seen one? My experience is Cisco tends to not call out what doesn't
work...you have to discover it out..
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Third Party CDR Analysis

[UC Penguin]

I should also add that this would be used primarily for reporting for 
individual departments/groups. Ex. How many calls are they getting over the 
normal volume, etc.  Is this employee making the phone calls they are required 
for their job responsibilities, etc. Again, technology trying to solve problems 
that are better managed in other ways :(

I’ve rolled my own CDR logging that loads the records in a database from 
multiple clusters and automatically purges them after our retention period. 
This works great for the occasional forensics request and troubleshooting 
general issues.

However, it doesn’t scale well for random ad hoc reports, schedule reports, etc 
without some more work.

Today charge back and DID management is done with a different product that has 
it’s own set of issues. It has some reporting capabilities but they don’t work 
well and are slow and cumbersome.

Variphy promotes their “cradle to grave reporting” though I’ve not looked at 
that portion yet. The other reports appear to be customized for almost anything 
in the CDR data with some stats as well, percent to vm, average duration etc, 
some what like CUIC without the hassle of CUIC and it’s interface.

I have a feeling this will likely end with us rolling our own reporting tools. 
As the reports will be demanded, but consensus on everyone’s requirements and 
the money to solve that will probably be difficult to obtain given the events 
of this year. Probably not the best use of our time, but better then the never 
ending requests for reports.

Thank you all for the responses, it’s appreciated.


> On Jun 3, 2020, at 16:38, Anthony Holloway  
> wrote:
> 
> 
> My personal experience is that it gets talked about a lot, but then never 
> purchased.  For mostly cost reasons, but I think it's also the fact that it's 
> one more vendor, one more contract, one more vm, one more management touch 
> point, etc., and is the data you'll get really that useful, to warrant all 
> that?
> 
> I personally have really wanted to see someone buy the Variphy suite, as it 
> also does DID management and a few other things.
> 
> I know the Donoma people post to this list often, so we might hear from them. 
>  Their website touts "telling a story" about the call, which I think is what 
> most are missing.  They just don't turn data into knowledge.  I'd like to see 
> Donoma pull that off, but again, I just don't see people buying anything. 
> 
>> On Wed, Jun 3, 2020 at 3:58 PM UC Penguin  wrote:
>> I’m curious what third party CDR Analysis software is commonly used today 
>> and pros/cons of each?
>> 
>> Looking for something friendly for non-Engineers to run reports.
>> 
>> Thanks in advance  
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] vCUBE Experiences

[Tim Smith]

Great question, also interested in hearing production stories.

I've deployed Virtual Acme Packet's previously - same limitations - no DSP's 
etc.
It was a little early and we had teething issues of appliance to virtual 
machine type stuff.. but through the updates this improved.

I've played with CUBE on CSR1000V on AWS - SIP trunks to Twilio - and it works 
great.
It's certainly so nice and easy to spin up.
I've also run CSR1000V in AWS for dynamic VPN's.. which again works great.

The DSP's are a nice fallback. You don't need them 99% of the time.. but when 
that 1% case comes up later - then it's certainly handy.
I think that's a big reason vCUBE is not quoted in customer land.
I assume it could be popular in service provider land though.

With that Acme deployment (and this was actually years ago now) - we were 
migrating, so we still had PRI gateways with plenty of free DSP's, which we 
could use for Transcoders if required.

Cheers,

Tim.






From: cisco-voip  on behalf of Anthony 
Holloway 
Sent: Thursday, 4 June 2020 7:06 AM
To: Cisco VoIP Group 
Subject: [cisco-voip] vCUBE Experiences


EXTERNAL SENDER WARNING. This message was sent from outside your organisation. 
Please do not click links or open attachments unless you recognise the source 
of this email and know the content is safe.

Anyone have some vCUBEs out in production for a while, and willing to share 
their feelings and/or experiences with it?

Anything from deployment, to restrictions, to licensing, to upgrade processes, 
lessons learned, etc?

I think the obvious thing is the lack of DSP/PVDM since this is a virtual 
machine, but what else?

I don't come across these in the field at all, and I don't see them being 
proposed or quoted these days, despite vCUBE having been around for a few years 
now.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Third Party CDR Analysis

[Anthony Holloway]

My personal experience is that it gets talked about a lot, but then never
purchased.  For mostly cost reasons, but I think it's also the fact that
it's one more vendor, one more contract, one more vm, one more management
touch point, etc., and is the data you'll get really that useful, to
warrant all that?

I personally have really wanted to see someone buy the Variphy suite, as it
also does DID management and a few other things.

I know the Donoma people post to this list often, so we might hear from
them.  Their website touts "telling a story" about the call, which I think
is what most are missing.  They just don't turn data into knowledge.  I'd
like to see Donoma pull that off, but again, I just don't see people buying
anything.

On Wed, Jun 3, 2020 at 3:58 PM UC Penguin  wrote:

> I’m curious what third party CDR Analysis software is commonly used today
> and pros/cons of each?
>
> Looking for something friendly for non-Engineers to run reports.
>
> Thanks in advance
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [External] Re: Resolving Sectigo root expiration affecting MRA

[Hunter Fuller]

We are doing a lot more than MRA, but it all kinda got wrapped up together.
The initial report being "Jabber no worky," and of course I know it's cert
related, but in my head I'm like, "well that's either an Expressway-E issue
or a CUCM issue or some issue with the traversal zone or..."

I guess if you don't use SSO, the certs probably matter a lot less. But if
you do use SSO, a lot of things happen that look like MRA issues but are
actually SSO sign-in or ticket issues.

Regarding monitoring cert expiration, emails from the CA are our go-to, but
it doesn't help when it's their damn root that's expiring. They were
shockingly silent on that, and when they did say something, it was
basically "this won't affect anything!" Wow, thanks.

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering


On Wed, Jun 3, 2020 at 12:26 PM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Ah ok, in your original email you only mentioned MRA, and so I was very
> focused on how CUCM might need certs in the store for MRA.  You are in fact
> doing more than just MRA.  Got it.
>
> On Wed, Jun 3, 2020 at 11:35 AM Hunter Fuller  wrote:
>
>> We have a handful of reasons for the certs in CUCM, some to do with MRA,
>> some not.
>>
>>  - Users use the Self Care Portal, and some pickier browsers don't like
>> being sent the wrong root.
>>  - Something to do with SSO? I was never super clear on this. Either our
>> SSO IdP didn't trust the cert from UCM or the other way around. We fixed
>> both at the same time, so I guess I will never know.
>>  - We are, in fact, checking crypto for all the Expressway tunnels
>> (ExpE-ExpC tunnel as well as ExpC-CUCM).
>>
>> Honorable mention:
>>  - Because it's a bad idea to leave expired certs laying around in there,
>> and I never know what one of my colleagues may have configured that relies
>> on the TLS verify working. :)
>>
>> --
>> Hunter Fuller (they)
>> Router Jockey
>> VBH Annex B-5
>> +1 256 824 5331
>>
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Network Engineering
>>
>>
>> On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
>> avholloway+cisco-v...@gmail.com> wrote:
>>
>>> Hunter,
>>>
>>> I might be exposing a gap in my knowledge here, but why did you need
>>> these certs on CUCM?
>>>
>>> Cisco has now published a troubleshooting guide for this issue, and the
>>> article does not mention modifying CUCM cert store.
>>>
>>>
>>> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>>>
>>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>>
 All,

 If you use certs whose trust is derived from the Sectigo root that
 expired today, and your MRA isn’t working, I’ll try to save you a call to
 TAC.

 Do all of these things:

  - Load the new intermediates and root into callmanager-trust and
 tomcat-trust on all your UCMs
  - restart tomcat, tftp, and callmanager on those boxes
  - load the new intermediates and root into the CA trust store on all
 expressways
  - reboot the Expressway-Es

 If you need more detail or help, let me know, we just got off the phone
 with TAC. Hope it helps.

 --

 --
 Hunter Fuller (they)
 Router Jockey
 VBH Annex B-5
 +1 256 824 5331

 Office of Information Technology
 The University of Alabama in Huntsville
 Network Engineering
 ___
 cisco-voip mailing list
 cisco-voip@puck.nether.net
 https://puck.nether.net/mailman/listinfo/cisco-voip

>>>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Third Party CDR Analysis

[Lelio Fulgenzi]

I’d be interesting if any of them have ever resolved the issue with transferred 
calls and how they associate them for chargebacks. I remember asking one CDR 
company and they were completely in awe of the fact that transferred calls have 
to be addressed like a chain of calls.

From: cisco-voip  On Behalf Of Jason Aarons
Sent: Wednesday, June 3, 2020 5:06 PM
To: UC Penguin 
Cc: cisco-voip voyp list 
Subject: Re: [cisco-voip] Third Party CDR Analysis

CAUTION: This email originated from outside of the University of Guelph. Do not 
click links or open attachments unless you recognize the sender and know the 
content is safe. If in doubt, forward suspicious emails to 
ith...@uoguelph.ca

I am happy with ISI's Infortel cloud. 3 CUCMs and 5 Avayas. Helpful to still 
understand things like route lists/trunks and cause codes, but techie can setup 
reports and save/share them.

-jason

On Wed, Jun 3, 2020, 4:58 PM UC Penguin 
mailto:gen...@ucpenguin.com>> wrote:
I’m curious what third party CDR Analysis software is commonly used today and 
pros/cons of each?

Looking for something friendly for non-Engineers to run reports.

Thanks in advance
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] vCUBE Experiences

[Anthony Holloway]

Anyone have some vCUBEs out in production for a while, and willing to share
their feelings and/or experiences with it?

Anything from deployment, to restrictions, to licensing, to upgrade
processes, lessons learned, etc?

I think the obvious thing is the lack of DSP/PVDM since this is a virtual
machine, but what else?

I don't come across these in the field at all, and I don't see them being
proposed or quoted these days, despite vCUBE having been around for a few
years now.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Third Party CDR Analysis

[Jason Aarons]

I am happy with ISI's Infortel cloud. 3 CUCMs and 5 Avayas. Helpful to
still understand things like route lists/trunks and cause codes, but techie
can setup reports and save/share them.

-jason

On Wed, Jun 3, 2020, 4:58 PM UC Penguin  wrote:

> I’m curious what third party CDR Analysis software is commonly used today
> and pros/cons of each?
>
> Looking for something friendly for non-Engineers to run reports.
>
> Thanks in advance
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Yeah, good question. Certificate monitor in cucm (and others) is really
handy for this, but I've also seen it fail due to a defect.

I wonder if the one cisco is using in cucm (and others) is the #8 one
listed in this article:
https://geekflare.com/monitor-ssl-certificate-expiry/

Either way, there's a few other cloud and on-prem solutions mentioned in
that link.

On Wed, Jun 3, 2020 at 1:24 PM Pawlowski, Adam  wrote:

> This is the boat we were in as well, and I’ve learned some lessons here.
>
>
>
> The bug that I posted about for Jabber mobile devices got me – since we’re
> MRA only I thought I broke it again and it took a while to figure out why.
> The bugs in Expressway  login banner got me for a while thinking I’d just broken the cluster due to
> the replication failed alarms.  I nearly forgot to reset all the phones
> after restarting TVS but … well fool me once on that one.
>
>
>
> I learned that the Expressway doesn’t have any real certificate “monitor”,
> and if you put an EC cert from an intermediate into the ipsec-trust
> keychain you will break that service, it will just core endlessly.
>
>
>
> How is everyone keeping track of the certificates that they have out
> there, and that they’re coming up due for replacement? Outlook calendars
> are no good, and neither are the notices from the issuing CA. I have to be
> missing something obvious.
>
>
>
> Best,
>
>
>
> Adam
>
>
>
> *From:* cisco-voip  *On Behalf Of *Derek
> Andrew
> *Sent:* Wednesday, June 3, 2020 10:20 AM
> *To:* Anthony Holloway 
> *Cc:* voyp list, cisco-voip (cisco-voip@puck.nether.net) <
> cisco-voip@puck.nether.net>
> *Subject:* Re: [cisco-voip] Resolving Sectigo root expiration affecting
> MRA
>
>
>
> If you had previously installed the certs on CUCM CUP CUC and CER as we
> did, they would also have expired.
>
>
>
> On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
> CAUTION: This email originated from outside of the University of
> Saskatchewan. Do not click links or open attachments unless you recognize
> the sender and know the content is safe. If in doubt, please forward
> suspicious emails to phish...@usask.ca
>
>
>
> Hunter,
>
>
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
>
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
>
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
> All,
>
>
>
> If you use certs whose trust is derived from the Sectigo root that expired
> today, and your MRA isn’t working, I’ll try to save you a call to TAC.
>
>
>
> Do all of these things:
>
>
>
>  - Load the new intermediates and root into callmanager-trust and
> tomcat-trust on all your UCMs
>
>  - restart tomcat, tftp, and callmanager on those boxes
>
>  - load the new intermediates and root into the CA trust store on all
> expressways
>
>  - reboot the Expressway-Es
>
>
>
> If you need more detail or help, let me know, we just got off the phone
> with TAC. Hope it helps.
>
>
>
> --
>
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
> --
>
> Copyright 2020 Derek Andrew (excluding quotations)
>
> +1 306 966 4808
>
> Communication and Network Services
>
> Information and Communications Technology
>
>
> *University of Saskatchewan *Peterson 120; 54 Innovation Boulevard
> Saskatoon,Saskatchewan,Canada. S7N 2V3
> Timezone GMT-6
>
>
>
> Typed but not read.
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

[cisco-voip] Third Party CDR Analysis

[UC Penguin]

I’m curious what third party CDR Analysis software is commonly used today and 
pros/cons of each?

Looking for something friendly for non-Engineers to run reports.

Thanks in advance  
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [External] Re: Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Ah ok, in your original email you only mentioned MRA, and so I was very
focused on how CUCM might need certs in the store for MRA.  You are in fact
doing more than just MRA.  Got it.

On Wed, Jun 3, 2020 at 11:35 AM Hunter Fuller  wrote:

> We have a handful of reasons for the certs in CUCM, some to do with MRA,
> some not.
>
>  - Users use the Self Care Portal, and some pickier browsers don't like
> being sent the wrong root.
>  - Something to do with SSO? I was never super clear on this. Either our
> SSO IdP didn't trust the cert from UCM or the other way around. We fixed
> both at the same time, so I guess I will never know.
>  - We are, in fact, checking crypto for all the Expressway tunnels
> (ExpE-ExpC tunnel as well as ExpC-CUCM).
>
> Honorable mention:
>  - Because it's a bad idea to leave expired certs laying around in there,
> and I never know what one of my colleagues may have configured that relies
> on the TLS verify working. :)
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
>
>
> On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> Hunter,
>>
>> I might be exposing a gap in my knowledge here, but why did you need
>> these certs on CUCM?
>>
>> Cisco has now published a troubleshooting guide for this issue, and the
>> article does not mention modifying CUCM cert store.
>>
>>
>> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>>
>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>
>>> All,
>>>
>>> If you use certs whose trust is derived from the Sectigo root that
>>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>>> TAC.
>>>
>>> Do all of these things:
>>>
>>>  - Load the new intermediates and root into callmanager-trust and
>>> tomcat-trust on all your UCMs
>>>  - restart tomcat, tftp, and callmanager on those boxes
>>>  - load the new intermediates and root into the CA trust store on all
>>> expressways
>>>  - reboot the Expressway-Es
>>>
>>> If you need more detail or help, let me know, we just got off the phone
>>> with TAC. Hope it helps.
>>>
>>> --
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Pawlowski, Adam]

This is the boat we were in as well, and I’ve learned some lessons here.

The bug that I posted about for Jabber mobile devices got me – since we’re MRA 
only I thought I broke it again and it took a while to figure out why. The bugs 
in Expressway  On Behalf Of Derek Andrew
Sent: Wednesday, June 3, 2020 10:20 AM
To: Anthony Holloway 
Cc: voyp list, cisco-voip (cisco-voip@puck.nether.net) 

Subject: Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

If you had previously installed the certs on CUCM CUP CUC and CER as we did, 
they would also have expired.

On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway 
mailto:avholloway%2bcisco-v...@gmail.com>> 
wrote:
CAUTION: This email originated from outside of the University of Saskatchewan. 
Do not click links or open attachments unless you recognize the sender and know 
the content is safe. If in doubt, please forward suspicious emails to 
phish...@usask.ca

Hunter,

I might be exposing a gap in my knowledge here, but why did you need these 
certs on CUCM?

Cisco has now published a troubleshooting guide for this issue, and the article 
does not mention modifying CUCM cert store.

https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html

On Sat, May 30, 2020 at 7:02 PM Hunter Fuller 
mailto:hf0...@uah.edu>> wrote:
All,

If you use certs whose trust is derived from the Sectigo root that expired 
today, and your MRA isn’t working, I’ll try to save you a call to TAC.

Do all of these things:

 - Load the new intermediates and root into callmanager-trust and tomcat-trust 
on all your UCMs
 - restart tomcat, tftp, and callmanager on those boxes
 - load the new intermediates and root into the CA trust store on all 
expressways
 - reboot the Expressway-Es

If you need more detail or help, let me know, we just got off the phone with 
TAC. Hope it helps.

--

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip


--
Copyright 2020 Derek Andrew (excluding quotations)

+1 306 966 4808
Communication and Network Services
Information and Communications Technology
University of Saskatchewan
Peterson 120; 54 Innovation Boulevard
Saskatoon,Saskatchewan,Canada. S7N 2V3
Timezone GMT-6

Typed but not read.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] [External] Re: Resolving Sectigo root expiration affecting MRA

[Hunter Fuller]

We have a handful of reasons for the certs in CUCM, some to do with MRA,
some not.

 - Users use the Self Care Portal, and some pickier browsers don't like
being sent the wrong root.
 - Something to do with SSO? I was never super clear on this. Either our
SSO IdP didn't trust the cert from UCM or the other way around. We fixed
both at the same time, so I guess I will never know.
 - We are, in fact, checking crypto for all the Expressway tunnels
(ExpE-ExpC tunnel as well as ExpC-CUCM).

Honorable mention:
 - Because it's a bad idea to leave expired certs laying around in there,
and I never know what one of my colleagues may have configured that relies
on the TLS verify working. :)

--
Hunter Fuller (they)
Router Jockey
VBH Annex B-5
+1 256 824 5331

Office of Information Technology
The University of Alabama in Huntsville
Network Engineering


On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Hunter,
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
>> All,
>>
>> If you use certs whose trust is derived from the Sectigo root that
>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>> TAC.
>>
>> Do all of these things:
>>
>>  - Load the new intermediates and root into callmanager-trust and
>> tomcat-trust on all your UCMs
>>  - restart tomcat, tftp, and callmanager on those boxes
>>  - load the new intermediates and root into the CA trust store on all
>> expressways
>>  - reboot the Expressway-Es
>>
>> If you need more detail or help, let me know, we just got off the phone
>> with TAC. Hope it helps.
>>
>> --
>>
>> --
>> Hunter Fuller (they)
>> Router Jockey
>> VBH Annex B-5
>> +1 256 824 5331
>>
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Network Engineering
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Derek Andrew]

If you had previously installed the certs on CUCM CUP CUC and CER as we
did, they would also have expired.

On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> CAUTION: This email originated from outside of the University of
> Saskatchewan. Do not click links or open attachments unless you recognize
> the sender and know the content is safe. If in doubt, please forward
> suspicious emails to phish...@usask.ca
>
> Hunter,
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
>> All,
>>
>> If you use certs whose trust is derived from the Sectigo root that
>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>> TAC.
>>
>> Do all of these things:
>>
>>  - Load the new intermediates and root into callmanager-trust and
>> tomcat-trust on all your UCMs
>>  - restart tomcat, tftp, and callmanager on those boxes
>>  - load the new intermediates and root into the CA trust store on all
>> expressways
>>  - reboot the Expressway-Es
>>
>> If you need more detail or help, let me know, we just got off the phone
>> with TAC. Hope it helps.
>>
>> --
>>
>> --
>> Hunter Fuller (they)
>> Router Jockey
>> VBH Annex B-5
>> +1 256 824 5331
>>
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Network Engineering
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>

-- 
Copyright 2020 Derek Andrew (excluding quotations)

+1 306 966 4808
Communication and Network Services
Information and Communications Technology

*University of Saskatchewan*Peterson 120; 54 Innovation Boulevard
Saskatoon,Saskatchewan,Canada. S7N 2V3
Timezone GMT-6

Typed but not read.
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Actually, I'm starting to think on this some more, I think it might be
because of two facts, but please confirm:

1) You signed your C certs with a public CA which leverages these expired
CA certs
2) You enabled TLS verification between CUCM and C (both MRA and B2B?)

I don't typically see encryption on the inside like this, though, I do see
it mentioned in the steps for MRA as if it were a requirement (e.g., how it
says to copy the names of the phone sec prof for the cert).  Though, I also
don't see a lot of B2B deployments where you might want E2E encryption
either.

On Wed, Jun 3, 2020 at 8:28 AM Anthony Holloway <
avholloway+cisco-v...@gmail.com> wrote:

> Hunter,
>
> I might be exposing a gap in my knowledge here, but why did you need these
> certs on CUCM?
>
> Cisco has now published a troubleshooting guide for this issue, and the
> article does not mention modifying CUCM cert store.
>
>
> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>
> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>
>> All,
>>
>> If you use certs whose trust is derived from the Sectigo root that
>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>> TAC.
>>
>> Do all of these things:
>>
>>  - Load the new intermediates and root into callmanager-trust and
>> tomcat-trust on all your UCMs
>>  - restart tomcat, tftp, and callmanager on those boxes
>>  - load the new intermediates and root into the CA trust store on all
>> expressways
>>  - reboot the Expressway-Es
>>
>> If you need more detail or help, let me know, we just got off the phone
>> with TAC. Hope it helps.
>>
>> --
>>
>> --
>> Hunter Fuller (they)
>> Router Jockey
>> VBH Annex B-5
>> +1 256 824 5331
>>
>> Office of Information Technology
>> The University of Alabama in Huntsville
>> Network Engineering
>> ___
>> cisco-voip mailing list
>> cisco-voip@puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

True, however, if they're not being used, it causes no issue, correct?
Much like the expiring root cert of Feb 2020 for Smart Call Home.

On Wed, Jun 3, 2020 at 9:20 AM Derek Andrew  wrote:

> If you had previously installed the certs on CUCM CUP CUC and CER as we
> did, they would also have expired.
>
> On Wed, Jun 3, 2020 at 7:34 AM Anthony Holloway <
> avholloway+cisco-v...@gmail.com> wrote:
>
>> CAUTION: This email originated from outside of the University of
>> Saskatchewan. Do not click links or open attachments unless you recognize
>> the sender and know the content is safe. If in doubt, please forward
>> suspicious emails to phish...@usask.ca
>>
>> Hunter,
>>
>> I might be exposing a gap in my knowledge here, but why did you need
>> these certs on CUCM?
>>
>> Cisco has now published a troubleshooting guide for this issue, and the
>> article does not mention modifying CUCM cert store.
>>
>>
>> https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html
>>
>> On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:
>>
>>> All,
>>>
>>> If you use certs whose trust is derived from the Sectigo root that
>>> expired today, and your MRA isn’t working, I’ll try to save you a call to
>>> TAC.
>>>
>>> Do all of these things:
>>>
>>>  - Load the new intermediates and root into callmanager-trust and
>>> tomcat-trust on all your UCMs
>>>  - restart tomcat, tftp, and callmanager on those boxes
>>>  - load the new intermediates and root into the CA trust store on all
>>> expressways
>>>  - reboot the Expressway-Es
>>>
>>> If you need more detail or help, let me know, we just got off the phone
>>> with TAC. Hope it helps.
>>>
>>> --
>>>
>>> --
>>> Hunter Fuller (they)
>>> Router Jockey
>>> VBH Annex B-5
>>> +1 256 824 5331
>>>
>>> Office of Information Technology
>>> The University of Alabama in Huntsville
>>> Network Engineering
>>> ___
>>> cisco-voip mailing list
>>> cisco-voip@puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>
>
> --
> Copyright 2020 Derek Andrew (excluding quotations)
>
> +1 306 966 4808
> Communication and Network Services
> Information and Communications Technology
>
> *University of Saskatchewan*Peterson 120; 54 Innovation Boulevard
> Saskatoon,Saskatchewan,Canada. S7N 2V3
> Timezone GMT-6
>
> Typed but not read.
>
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip

Re: [cisco-voip] Resolving Sectigo root expiration affecting MRA

[Anthony Holloway]

Hunter,

I might be exposing a gap in my knowledge here, but why did you need these
certs on CUCM?

Cisco has now published a troubleshooting guide for this issue, and the
article does not mention modifying CUCM cert store.

https://www.cisco.com/c/en/us/support/docs/unified-communications/expressway/215561-troubleshooting-expressway-mra-login-and.html

On Sat, May 30, 2020 at 7:02 PM Hunter Fuller  wrote:

> All,
>
> If you use certs whose trust is derived from the Sectigo root that expired
> today, and your MRA isn’t working, I’ll try to save you a call to TAC.
>
> Do all of these things:
>
>  - Load the new intermediates and root into callmanager-trust and
> tomcat-trust on all your UCMs
>  - restart tomcat, tftp, and callmanager on those boxes
>  - load the new intermediates and root into the CA trust store on all
> expressways
>  - reboot the Expressway-Es
>
> If you need more detail or help, let me know, we just got off the phone
> with TAC. Hope it helps.
>
> --
>
> --
> Hunter Fuller (they)
> Router Jockey
> VBH Annex B-5
> +1 256 824 5331
>
> Office of Information Technology
> The University of Alabama in Huntsville
> Network Engineering
> ___
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
___
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip