AES Jan 6th Certificate expiration (PSN004561u)

[janni78]

If I've understood this correctly the switch connection between CM and AES will not be affected by this since it uses the CMs certificate?

Only have one customer using encrypted TSAPI and DMCC so this would need to be handled but all others are just using unencrypted TSAPI.

"Trying is the first step to failure..." - Homer

 

[kyle555]

If AES-->CM is encrypted then it's most likely CM that's offering it's default cert to AES and unrelated to the default AES cert that's offered out to other applications.

Are you at 7.1? Everything needs to be mutual TLS there, so the demo stuff probably wouldn't have worked in the first place.

The one I'm dealing with is looking through Verint Impact360. It's clearly accepting the default cert AES offers and I looked through a Verint and it looks like it just has it's own Java JDK/JRE embedded in it's install folder with the generic CA certificates that come with Java, to say nothing special about trusting that Avaya default authority. That leads me to think it doesn't care what CA issues the new AES cert - like using your SMGR.

The way I see it is either go unencrypted or renew the AES cert from something SMGR which should entail popping the SMGR CA cert in the 3rd party app hitting AES if they take security seriously. Could be a bit of a wildcard.

 

[janni78]

I have AES 6 on CM 5.2.1, they are using Nice and CCE with encrypted links. (finally replacing this in a couple of months)
For example the TSAPI is only encrypted between AES and the TSAPI client.

There is a cert directory in the TSAPI client install with a Avaya Root CA cert.
Seems the be a similar for CMAPI/DMCC used by Nice.

Gonna try creating a new cert tonight when the they have closed the CC.

"Trying is the first step to failure..." - Homer

 

[mattKnight]

There is a non he patch that extends the very lifetime...

I tried use a proper PKI cert with sea and Nice and it failed.... cert is ok with Aww as other sea servers come up with encrypted dmcc. Nice just wasn't playing - so unless the root cert needs to installed in Nice somewhere other than in the windows very stores.. .

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[kyle555]

Looks like matt was typing from a cell phone!

DMCC encrypted doesn't use a cert, but if you specify your TLINK as swlink1-CSTA-S-etc-etc and not just CSTA, then your application will try TLS ports 1066-1081 and not TCP ports 1050-1065.

If your Nice works on a Windows server, maybe they do things like Verint. Verint told me that they just use the same Windows TSAPI client with TSAPI Spy that you can download from devconnect and their application literally uses that client to establish it's TSAPI. In it's installation folder there's a /certificates/ca directory that you can drop your CA cert into.

Otherwise, Verint also has a built-in Java virtual machine/JDK and I checked it's certificate stores and there's nothing specific to any PBX vendor like "Avaya Root CA that signed the default AES cert". They seem to only leverage Java and the java key store for their SIP stack for SIPREC.

 

[janni78]

Not done but so far so good.
I made a new CA on the AES server using OpenSSL.

I had to copy the CA cert to the TSAPI client install and point to it in TSLIB.INI
Trusted CA File=C:\Program Files (x86)\Avaya\AE Services\TSAPI Client\certs\ca\cacert.cer

Looks like DMCC uses Windows Certificate store so I might need to import it there to get Nice working.

"Trying is the first step to failure..." - Homer

 

[mattKnight]

Kyle - correct!

Interesting about the tslib.ini file. I'll look at that when I get back to work.



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[janni78]

Saw that with EMC they recommended you to copy you CA to the default "avayaprca.cer" file, guessing it's using that by default if nothing else is said in tslib.ini but haven't tested it yet.

"Trying is the first step to failure..." - Homer

 

[kyle555]

I got out clean!

I found that it's the same for any Windows TSAPI Client. You threw me for a bit of a loop when I tried messing with TSLIB.ini and adding a new file in there. Not that what you'd said was wrong, but my mistake was not looking at the certificate format of the avayaprca.cer first. avayaprca.cer is just a text file of pem certificates with ----BEGIN CERTIFICATE---- and ----END CERTIFICATE---- and not in base64 format (it looks like gibberish).

If you were to generate a new cert with SMGR, you can literally just go in SMGR's CA, download it's CA cert as PEM, open in notepad and copy/paste and append to the avayaprca.cer file and your Windows TSAPI client installation for any application should work.

All to say, it'd be nice if Avaya had a "readme.txt" in that /certificates/ca folder that said "you need to specify the file name in TSLIB.ini or just paste the pem at the bottom of the only other file in here".

Thanks!

 

[janni78]

All seems good on mine as well, finished it last night =)

Nice (DMCC) got up as soon as I installed the new root cert in Windows Certificate Store.

I changed tslib.ini for mine but nice to know it works by changing the avayaprca.cer

"Trying is the first step to failure..." - Homer

 

[John Besha]

Hi Janni78,

We have the same issue, our ACR has stopped recording the calls, the DMCC connection is down between the ACR and the AES.
We have issued new CA in the AES, and we have problem with importing it to the right file path in the ACR, please note that we have ACR on Windows deployment.

Regards,
John

 

[janni78]

For DMCC you should import the root certificate to Windows Certificate Store.

"Trying is the first step to failure..." - Homer

 

[John Besha]

Janni78,

Would you please share the detailed steps to do so?

Regards,
John

 

[janni78]

Try following [URL unfurl="true"]http://www.entrust.net/knowledge-base/technote.cfm?tn=8757[/url]

"Trying is the first step to failure..." - Homer