SMGR Certificates 1

[G van Hamburg]

Who has any clue about the new (post 6.3.8) SMGR certificates. I am trying to built a new system and thought that I needed to download the cert and import in CM. But after initTM and configuring tls to CM all is in service/idle. But at an other site I needed to use initTM -d to get the trunk to CM up and running. (-d is the demo cert) So how and where can I see what certificate is used?

Plan your work............Work your plan

 

[kyle555]

My understanding is that it is as of SM 6.3.8 and not necessarily SMGR 6.3.8 that SM forces the use of SMGR's cert and not the default one.

That said, you can check in the Inventory in SMGR and see what certificates (under 'More Actions') and see if that SM is permitting SIP connections with the default cert. If you upgraded to SM 6.3.8 from previous, there was a y/n question to do things the old way or the new way as part of the upgrade.

To make CM work, I think you have to put the cert in /var/home/ftp/pub and import it through a clunky web interface to make CM use a different cert for TLS.

To make Audiocodes gateways work, I had to generate a CSR and a private key, have the CA in SMGR sign it - through the EJBCA - which isn't exactly intuitive if you haven't done it before... and then take that cert generated for the Audiocodes and the SMGR cert and the private key generated with the CSR and put those 3 things into the gateway to get it up.

I've found some things/apps/devices are more permissive and will work happily with just the SMGR cert, and others won't use the certs you provide unless you did the whole validation chain properly - like how some people click "ignore" and go to the web page when it says the cert the page is presenting isn't from a trusted authority, and other people manage their domain security policies to prevent browsers from accepting certs that can't be validated all the way up to a trusted CA.

It can be a pain!

 

[G van Hamburg]

Thanks Kyle (if that is your name) for your help!

I think I found the missing link and I hope I can explain! I did a initTM -f which looses the old certificate (between SMGR and SM) and forces a new trust using the new SMGR CA certificate. After that, CM trunks are down and importing the certifcate in CM fixes it. So that’s cleared.
But why did this install take the demo certificate and an other install did not? What was the difference? I am not 100% sure but I think i know.

This install was on VMware and the other install was on physical hardware! After deploying both VMware machines the trust was built and (probably) the demo certificate wass use at that point. Upgrading to 6.3.11 still keeps this trust and only initTM -f will force the system to use the SMGR CA.

On the install with physical hardware I upgraded SMGR to 6.3.11 before I installed SM. So that’s why in that case the SMGR CA certificate was used.



Plan your work............Work your plan

 

[kyle555]

initTM -f forces a fresh load of the certificates for data replication between SM and SMGR. initTM -d forces SM to use the demo certificates for handling SIP.

Listen, when it comes to Avaya stuff, you can do the same thing 10 times and get 10 different results and have no friggin idea why. I find it helps most to just try and have a thorough understanding of how things work and treat each install like the precious unique little snowflake that it is!

 

[irvjam]

kyle555,
Kyle, Do you have the media pack gateway registering to SM via TLS?
I have been spinning my wheels on this for a while now, just heard from Avaya support that only supported configuration port from AudioCodes to Session Manager is TCP.
Originally I generated CSR from audiocodes and had our internal CA sign it, I think that's my problem since SMGR is the CA I need to have it signed through the EJBCA in SMGR. Could you expand on the process you performed to obtain the proper certs?

 

[kyle555]

Yeah. It works - and yes, you need to use the SMGR's CA to sign the cert signing request.

You can use the web gui in the Audiocodes to generate the CSR - or any pc with openssl and generate your keys and requests that way.

I believe the audiocodes requires you to load the key and the cert as separate files. Other things need you to convert them to like a pkcs12 file that include both in one.

Anyway, high level...
From SMGR HOME-->Security-->Certificates-->Authority-->Add End Entity.

Let it use the default profile of "Inbound Outbound TLS" - give it a user/pass - like test and test123 and fill out the common name as the FQDN of the audiocodes gateway if you like.

Then click on "public web", "create server certificate" and paste the contents of the CSR you generated in any old openssl or on the audiocodes itself into the box and the user/pass combo you made. The output should be a certificate!

 

[irvjam]

Thanks kyle555 it works. here's a star

 

[irvjam]

Second question. I have to do this for all of these gateways?
ie - If I have 20 MP114's in my network I would have to have 20 End Entity's in SMGR, because each gateway has a different CSR, or is there an easier way???

 

[kyle555]

That's what I was saying about using openssl in a command line to generate your request and key, sign it once in SMGR. Maybe the certificate CN could be instead of each MP114's fqdn be "myaudiocodesgateways.mydomain.com" and you could take the resulting cert and key file you made and push the same thing to all the audiocodes gateways.

Now, I am no security expert by ANY means, and figured most of this out screwing around myself, but as I understand it, a lot of the things that generate their own CSRs are going to keep the private key they signed that request with all to themselves.

So, I don't know if there's a way you'd be able to make 1 CSR with a key on 1 gateway and push it to the other 20, but I think if you just use openssl at the CLI of any Linux machine (your System Manager included...) that you could generate the 2 files needed and just load them on each audiocodes thereafter.

 

[mattKnight]

You should be able to do it with 1 certificate by adding all the audio codes fqdns or ip addresses to the SAN (subject alternative name) field as you generate the csr.



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.

 

[irvjam]

Currently setting these up at my desk using one IP address and they're not dns - yet...

I created csr using openssl had SMGR sign it, then loaded it on two mp114 FXS boxes so far, they both WILL register to SM TLS and can call out fine but they won't accept any incoming calls.
traceSM returns "500 server internal error."
MP114 LOg syays - "ERROR] TlsTransportObject#9- CSocket::HandleSocketEvent socket error received, error: Connection reset by peer(254)."