Session avaya tls versions windows#

You don't have the luxury of defining how stringent you can be on any given box. So, I signed a cert in SMGR for CM and wrapped it up as a PKCS12 with private key and once CM user that, I got my TLS up. Once I let CM trust the SMGR CA cert, CM accepted the SM cert offered and then still offered up it's default cert that SM then rejected. To say, with mutual TLS auth off in SM and just doing initTM, my TLS handshake in SM showed CM failed with an unknown CA error on the cert SM offered CM. Haven't bothered looking at CM to see if I can make it not offer a cert to SM. Ouch! So, I believe at 7.1 CM/SM do mutual TLS authentication even if it's turned off in SM.

Session avaya tls versions windows#

So, if you got all your Avaya endpoints internal/anything that goes direct to SM under your control and you can send them your SMGR CA cert as an authority they trust, and the mobile stuff is always through the SBC (as in, on corportate wifi resolves to the public IP and not the private one) you might be able to get away with just the SBC chaining up to the Windows domain CA. To say, the godaddy public cert for 'yourconferenceserver' is offered by the SBC and the SBC wnwraps that and rewraps it with a cert signed by SMGR towards 'yourconferenceserver' That's how you do the reverse proxy stuff for aura conferencing. Last choice, is if it's all through the SBC, you can just deal with the SBC offering the 'mysbc' cert signed by the Windows CA and have the SBC re-wrap all the TLS to the Aura core with the SMGR domain certs. You need 'identity certs' offered by SM that are from a CA your devices trust.Įither it's 3rd party everything and the domain guys sign all your server certs, or they let SMGR be a sub-CA so it's allowed to sign certs that still chain up to the Windows domain CA. Got to go through making SMGR a sub-CA of the windows domain so everything you do with SMGR chains up to the Windows CA. What am I missing? RE: Equinox kyle555 (TechnicalUser) 23 Jun 17 15:29Įesh. The only noticeable message I see is a Fault from the sm100 to the mobile client, which reads:Ģ2:2| .domain.PPMOperationFault | I get a load of appdata exchanges between the sm100 and the mobile client.

When I run a traceSM I see the client/server exchange messages and aren't seeing any errors. Then just entering the 4 digit extension and security code. On the client end I'm manually configuring the client and putting in the IP of the Security module, port 5061/tls and my domain. Those errors stopped and I'm now getting VoIP phone service Unavailable. I exported from SMGR/SM and installed manually on the device. I started out with certificate errors, which I believe I sorted.

At a very basic level, before testing externally via the SBC I just wanted to get the IOS client registered directly to SM internally.