I have stood up a new smgr/sm 7.1. Before moving on to the SBC I just wanted to test the equinox mobile app directly to SM to make sure it works. At just a basic level I just need to create a new SIP user. I exported the identity and trust certs from SM and SMGR and I keep getting cert errors. Would those not work by manually installing them on the mobile device?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Equinox 4
- Thread starter wpetilli
- Start date
- Thread starter
- #21
From the documentation it's understood that using the autoconfig method forces you to push the certs via the web server. That uses the private trust store of app on the device. If we wanted to push the required certs via MDM and still use autoconfig just for the settings (server name/dial plan), is that possible? It would kind of stink if the certs got pushed via MDM and the user would have to do manual type config.
- Thread starter
- #23
I was able to get that working.. in the 46xx file I used: SET TRUSTCERTS "" putting nothing between the quotes looks to have forced the device trust store and not the app private store.
Hopefully today the team that does the DNS will have those pointers all setup and I can get the certs finally cut. For the SBC cert they are planning to use a SAN cert. Aside from the URL that will point to the public IP of the SBC they want the SBC machine names. The servers themselves were deployed with unique hostnames, but after getting them commissioned the install of the application has 1 name that both SBC's have. I see that on the dashboard. I take it I'm providing the server hostnames? If so, what IP should DNS resolve to for those.. mngt, private..
Hopefully today the team that does the DNS will have those pointers all setup and I can get the certs finally cut. For the SBC cert they are planning to use a SAN cert. Aside from the URL that will point to the public IP of the SBC they want the SBC machine names. The servers themselves were deployed with unique hostnames, but after getting them commissioned the install of the application has 1 name that both SBC's have. I see that on the dashboard. I take it I'm providing the server hostnames? If so, what IP should DNS resolve to for those.. mngt, private..
That trustcerts line blank forces the device cert store? Awesome! That is very helpful!
As for the sbc certs, hostnames don't matter.
So long as the cert is issued to publicB1IP.ofmyactivepair.com and DNS resolves there, that's all the device will care about.
You need different hostnames for each unit of the HA pair, but because each will assume the active IP and offer a cert, all that matters is DNS and the cert. Bonus points if you set up dual data center and use DNS srv sip records. So, sip.you.com as a sip service lookup gets back sbcatDC1.you.com and sbcatDC2.you.com so the phone could point at 2 HA pairs. As far as I know the idea with subjectaltname is so you can have 1 cert for many things if they wind up being load balanced or used in a capacity like I'm describing.
As for the sbc certs, hostnames don't matter.
So long as the cert is issued to publicB1IP.ofmyactivepair.com and DNS resolves there, that's all the device will care about.
You need different hostnames for each unit of the HA pair, but because each will assume the active IP and offer a cert, all that matters is DNS and the cert. Bonus points if you set up dual data center and use DNS srv sip records. So, sip.you.com as a sip service lookup gets back sbcatDC1.you.com and sbcatDC2.you.com so the phone could point at 2 HA pairs. As far as I know the idea with subjectaltname is so you can have 1 cert for many things if they wind up being load balanced or used in a capacity like I'm describing.
- Thread starter
- #25
The SBC doesn't need to have anything in the certs that reference Session Manager? Since I'll be adding regional SBC's and would use geo load balancing in DNS.. for testing purposes if I wanted to bypass that and point directly to a specific SBC cluster does adding the SBC hostnames into the SAN make sense?
I was speaking about SBC's outside certs only that just need DNS + cert subjectaltname to satisfy the outside device.
Inside, unless you force mutual authentication on SM, SM won't require the SBC to present a cert, it'll just require that the SBC trust the CA signing SM's cert.
If you do mutual TLS, then the SBC needs a cert signed to it, and if SM is stringently checking (dunno if that's forced or administerable) then the DNS lookup of the CN/subjectAltName of the cert offered by the SBC must be DNS resolvable to its internal A1 IP.
Same idea really. Just like the server responding on amazon.com has that cert for its web service, but you can bet his real hostname in the amazon DC is not really amazon.com
Inside, unless you force mutual authentication on SM, SM won't require the SBC to present a cert, it'll just require that the SBC trust the CA signing SM's cert.
If you do mutual TLS, then the SBC needs a cert signed to it, and if SM is stringently checking (dunno if that's forced or administerable) then the DNS lookup of the CN/subjectAltName of the cert offered by the SBC must be DNS resolvable to its internal A1 IP.
Same idea really. Just like the server responding on amazon.com has that cert for its web service, but you can bet his real hostname in the amazon DC is not really amazon.com
- Thread starter
- #28
I think I remembered what was bugging me about that whole iOS thing.
It kinda makes sense to me...
So, Apple's Keychain with trusted root CA certificates is available to all apps. When you set trustcerts "smgr", it fails to do that and trusts nothing. It can't import certs into the CA trust store of the device and if it were possible to configure an app to trust any CA undercover/under the hood, then my malicious app just needs to be told to trust Kyle's CA and you get a happy green secure lock trusting an arbitrary authority.
The part I was right about is if you wanted to do mutual TLS authentication from SM to iOS and back from iOS to the SM - that's where you need the PKCS12 with private key, and that's the part iOS won't let any non-Apple app tie into the keychain and get that cert - it must be bundled with the app. Otherwise, malicious app X can use that cert to validate identity, to say, your mail server, and do something nefarious like say, read your email and send it to me.
Avaya's got configurator tools for various clients. Aura Conferencing's Outlook plugin, or Communicator for Lync are examples. You download and run a "installation builder" and it spits out a .exe or .msi you push to your PCs. So, like in the softphones where you punch in server IP etc, Communicator for Lync doesn't let you. Your admin built a .msi where he put in those parameters and what's pushed to the device is the app with all config locked down. I suppose something like that might need to exist for Equinox eventually because you'd need Avaya to sign your app+PKCS12 with their Apple Vendor rubber stamp to get a Equinox version with your specific PKCS12, or they'd need to let you rebuild their app with your PCKS12 and have it signed by you and it'd be something you deploy like any other private enterprise app not on the app store.
I think this is somewhere the whole PKI discussion is going to go more and more. All the stuff I see about it is about how to make the client trust your 3rd party CA that issued the server the cert. I don't really care about that - I'm concerned about protecting the communications core and using certificates on the client that the server must trust before handshaking TLS and allowing a login attempt. Anyone can wireshark a TLS handshake failure and export the CA cert the server offered and trust it to get past that level.
It kinda makes sense to me...
So, Apple's Keychain with trusted root CA certificates is available to all apps. When you set trustcerts "smgr", it fails to do that and trusts nothing. It can't import certs into the CA trust store of the device and if it were possible to configure an app to trust any CA undercover/under the hood, then my malicious app just needs to be told to trust Kyle's CA and you get a happy green secure lock trusting an arbitrary authority.
The part I was right about is if you wanted to do mutual TLS authentication from SM to iOS and back from iOS to the SM - that's where you need the PKCS12 with private key, and that's the part iOS won't let any non-Apple app tie into the keychain and get that cert - it must be bundled with the app. Otherwise, malicious app X can use that cert to validate identity, to say, your mail server, and do something nefarious like say, read your email and send it to me.
Avaya's got configurator tools for various clients. Aura Conferencing's Outlook plugin, or Communicator for Lync are examples. You download and run a "installation builder" and it spits out a .exe or .msi you push to your PCs. So, like in the softphones where you punch in server IP etc, Communicator for Lync doesn't let you. Your admin built a .msi where he put in those parameters and what's pushed to the device is the app with all config locked down. I suppose something like that might need to exist for Equinox eventually because you'd need Avaya to sign your app+PKCS12 with their Apple Vendor rubber stamp to get a Equinox version with your specific PKCS12, or they'd need to let you rebuild their app with your PCKS12 and have it signed by you and it'd be something you deploy like any other private enterprise app not on the app store.
I think this is somewhere the whole PKI discussion is going to go more and more. All the stuff I see about it is about how to make the client trust your 3rd party CA that issued the server the cert. I don't really care about that - I'm concerned about protecting the communications core and using certificates on the client that the server must trust before handshaking TLS and allowing a login attempt. Anyone can wireshark a TLS handshake failure and export the CA cert the server offered and trust it to get past that level.
- Thread starter
- #30
I don't know what's going on with this, but I'm unable to get an ios equinox client registered directly at SM. I'm getting the red triangle with: voip service is currently available with limited service. The client actually looks logged in, but when trying to do anything with it, like make a call, they fail. When I run the traceSM it looks like the TLS handshake process is good. When I sort by d=calls I see the extension - SM with remote host not trusted followed by 407 proxy auth requests. After the 100 tryings the server sends back a 500 server internal error. Within that msg I'm not seeing anything tangible as to why.
The client is a configured SIP station and tied to a managed CM element, with SM as its primary and the application sequences. Entity links between are all good. The SM dashboard is greens all across. I've rebooted everything and not making any progress. Any ideas what I can check?
The client is a configured SIP station and tied to a managed CM element, with SM as its primary and the application sequences. Entity links between are all good. The SM dashboard is greens all across. I've rebooted everything and not making any progress. Any ideas what I can check?
- Thread starter
- #32
Going to try a hardphone, but I'm not finding anything standing out that's off. I keep getting the triangle about 'voice service limited'. The traceSM keeps eventually spitting a 500 Server Internal Error with message 'Endpoint termination failed'. Not seeing anything relevant.
- Thread starter
- #34
The CM is a managed element on the same SMGR as the SM. There's also an entity link between the CM and the SM... CM SG/TG to the SM. AAR entry SIP station created on SMGR with IP softphone and visible in CM. Application Sequences applied to station and using set type 9641SIP/9641SIP_Default_CM6_3. Equinox setup to the SM-100 with assigned domain. Private number has SIP extension with TG to SM.
- Thread starter
- #36
Yes for the testing it's just 1. There's a second sitting there waiting I can bring in. I logged in a regular h.323 phone and tried to call that SIP station and saw the traffic go over the SIP trunk and saw it fail at SM in the trace with the same 500.
- Thread starter
- #37
- Thread starter
- #39
The CM codec sets are defined per the doc.. Yes, using TLS all the way from client to connections between SM and CM. I'm not even involving the SBC yet, I'm just trying to get registered directly to SM before anything.
I keep going back to the certs because we cut our own SAN certs and replaced the SM Identity certs for the security module_sip and http and installed/added our root/subca certs into the SMGR trust store. for TM_OUTBOUND_TLS AND INBOUND. I'm getting passed the TLS handshake though with no errors. It goes right to those application data msg's.. registration/subscribe and then things fall apart.
I keep going back to the certs because we cut our own SAN certs and replaced the SM Identity certs for the security module_sip and http and installed/added our root/subca certs into the SMGR trust store. for TM_OUTBOUND_TLS AND INBOUND. I'm getting passed the TLS handshake though with no errors. It goes right to those application data msg's.. registration/subscribe and then things fall apart.
- Thread starter
- #40
- Status
Similar threads
