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
- #61
The SBC has the CA/SUBCA chain cert on it and the SM has both of them installed separately (not as a chain). Forgot why the SM didn't like the chain, but.. In any event this is a cert issue after all. I re-ran a traceSM, shutdown SBC2 and restarted the application on SBC1. The traceSM pumped the fatal cert errors about an unknown CA, which doesn't make sense. Since both are cut from the same.
- Thread starter
- #63
So, welcome to SBC certificate hell
There's something in the TLS profile about depth where you might need all the intermediate certs up to the CA, not just the CA cert. Web browsers don't validate intermediate certs, the SBC does.
Then, i can't remember if cat'ing many pems together of them, or converting to a pkcs7 might be needed, but suffice to say, whatever SM is offering the SBC, it doesn't like.
Just for yucks, point the SBC at your CM or AAM. For no other reason that to prove the TLS handshake. CM or AAM should still probably offer the demo cert and you'll see if your SBC likes it. If that's the case, then you know the SBC isn't accepting what you've administered and I can give you some pointers on that.
There's something in the TLS profile about depth where you might need all the intermediate certs up to the CA, not just the CA cert. Web browsers don't validate intermediate certs, the SBC does.
Then, i can't remember if cat'ing many pems together of them, or converting to a pkcs7 might be needed, but suffice to say, whatever SM is offering the SBC, it doesn't like.
Just for yucks, point the SBC at your CM or AAM. For no other reason that to prove the TLS handshake. CM or AAM should still probably offer the demo cert and you'll see if your SBC likes it. If that's the case, then you know the SBC isn't accepting what you've administered and I can give you some pointers on that.
- Thread starter
- #65
- Thread starter
- #66
Winner winner chicken dinner.. changed verification depth to 3 (I tried 2 yesterday and it didn't work and I moved on from that being the issue) and that connection is now up. Testing client from externally and now getting fault messages during that application exchange. Going to try bouncing the service on SM.
- Thread starter
- #67
The SBC is sending the 'get' messages and SM is returning a Fault with the contents being
|<SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:ns0="23:41:34|apache.org/axis/">ns0:Server.Unauthenticated</faultcode> |
23:41:35|<faultstring>challenge</faultstring> |
23:41:35|</SOAP-ENV:Fault> |
23:41:35|</SOAP-ENV:Body> |
23:41:35|</SOAP-ENV:Envelope>
|<SOAP-ENV:Envelope xmlns:SOAP-ENV=" xmlns:ns0="23:41:34|apache.org/axis/">ns0:Server.Unauthenticated</faultcode> |
23:41:35|<faultstring>challenge</faultstring> |
23:41:35|</SOAP-ENV:Fault> |
23:41:35|</SOAP-ENV:Body> |
23:41:35|</SOAP-ENV:Envelope>
- Thread starter
- #69
When I attempt a connection now, the error on the client I now get is invalid ex or password which I know is correct. The SBC incidents show a 'no subscriber flow match'. The User agents I have are:
Avaya one-X Communicator Avaya one-X Communicator.*
Avaya Communicator Avaya Flare.*
Deskphone 96x1 Avaya one-X Deskphone.*
Avaya Communicator for iPhone *
The subscriber flows:
1 RemoteWorker96x1TLS-SRTP * * Deskphone 96x1 RemoteWorkersSRTP
2 RemoteWorkerCommunicat... * * Avaya Communicator RemoteWorkersSRTP
3 Rem Worker one-XC TLS-... * * Avaya one-X Communicator RemoteWorkersSRTP
4 Avaya Communicator for... * * Avaya Communicator for iphone RemoteWorkersSRTP
I put these in exactly from the doc, so I'm not convinced these are wrong.
Avaya one-X Communicator Avaya one-X Communicator.*
Avaya Communicator Avaya Flare.*
Deskphone 96x1 Avaya one-X Deskphone.*
Avaya Communicator for iPhone *
The subscriber flows:
1 RemoteWorker96x1TLS-SRTP * * Deskphone 96x1 RemoteWorkersSRTP
2 RemoteWorkerCommunicat... * * Avaya Communicator RemoteWorkersSRTP
3 Rem Worker one-XC TLS-... * * Avaya one-X Communicator RemoteWorkersSRTP
4 Avaya Communicator for... * * Avaya Communicator for iphone RemoteWorkersSRTP
I put these in exactly from the doc, so I'm not convinced these are wrong.
- Thread starter
- #71
I had to register directly to SM to see the register detail and it has user agent: Avaya Communicator for iPhone/3.2. I put a reg entry for Avaya Communicator for iPhone/3.2.* and it still didn't work. I rebooted the bloody thing and it works now. OMG.. This was by far the biggest nightmare of an install. Still have much to do, but this was the major piece. Thanks for help and patience.. owe you big time.
- Thread starter
- #72
If you don’t mind I need to recap this one last time because just when I think I have this at the 2 yard line a conversation with my AD guys brings me back to square 1. Our initiative is remote workers using iOS and hard phones. Our iOS devices are managed by MDM and have our CA certs pushed to all devices by policy. The idea was to not deploy anything to the iPhones as long as the Avaya servers had our CA in its trust store.
For the SBC: We cut a cert for the SBC where the DNS name resolves to the public IP address that NATs to the B1 interface. We also included other DNS names in the SAN that resolve to the B1 interface directly and the future DNS names of the SBC’s that aren’t deployed yet. No references to ASM’s.. just those. We are going with the method that even internal folks will go up to the SBC to avoid complicating things.
For ASM: we replaced the identity certs with our own (same cert in all containers). That cert has the DNS names of all the global ASM’s in the SAN. We also installed our Root/SubCA certs in the ASM and SMGR trust stores.
For CM: we installed our Root/SubCA certs in the trust store only.
ASM is set to ‘None’ for TLS Endpoint Cert Validation
The 46xx file for equinox clients has TRUSTCERTS “” so it uses the device trust store and not private trust store. The TLSSRVID is 0.
I get successful registration with the iOS devices and full functionality. If a user leaves the firm they just wipe the policy via MDM and that phone becomes disabled.
For the hardphones I’ve tested deploying our root/subca cert along with a cert via SCEP. In the 46xx file for these phones.. same deal with the TLSSRVD at 0. I get successful registration.
The confusion I have is based on this setup are these secure from a security standpoint to put out in prod and if not what did I miss?
The other part is around the hard phone revocation process. I know those phones need an identity cert via SCEP and a CRL on the SBC. But it sounds from my A/D team that if we’re not doing mutual authentication then that entire process will not work and nothing will stop the phone from coming through. That would toss a monkey wrench in this whole process and I need to be able to do that.
j
For the SBC: We cut a cert for the SBC where the DNS name resolves to the public IP address that NATs to the B1 interface. We also included other DNS names in the SAN that resolve to the B1 interface directly and the future DNS names of the SBC’s that aren’t deployed yet. No references to ASM’s.. just those. We are going with the method that even internal folks will go up to the SBC to avoid complicating things.
For ASM: we replaced the identity certs with our own (same cert in all containers). That cert has the DNS names of all the global ASM’s in the SAN. We also installed our Root/SubCA certs in the ASM and SMGR trust stores.
For CM: we installed our Root/SubCA certs in the trust store only.
ASM is set to ‘None’ for TLS Endpoint Cert Validation
The 46xx file for equinox clients has TRUSTCERTS “” so it uses the device trust store and not private trust store. The TLSSRVID is 0.
I get successful registration with the iOS devices and full functionality. If a user leaves the firm they just wipe the policy via MDM and that phone becomes disabled.
For the hardphones I’ve tested deploying our root/subca cert along with a cert via SCEP. In the 46xx file for these phones.. same deal with the TLSSRVD at 0. I get successful registration.
The confusion I have is based on this setup are these secure from a security standpoint to put out in prod and if not what did I miss?
The other part is around the hard phone revocation process. I know those phones need an identity cert via SCEP and a CRL on the SBC. But it sounds from my A/D team that if we’re not doing mutual authentication then that entire process will not work and nothing will stop the phone from coming through. That would toss a monkey wrench in this whole process and I need to be able to do that.
j
Good on ya for sending everyone in or out thru the SBC.
So, yeah, without mutual TLS on the outside, all the endpoints need to do is trust your root CA. Your root CA cert is not private or under your control. If I go to and get a cert for yourinternalwebsite that chains up to the rootCA, I can take that cert, pop it in my device and get a login prompt.
Managing CRLs on the SBC and enforcing mutual TLS on his outside is what they want. Even on the SM inside, that's just going to make the SBC-->SM mutual TLS. You could have TCP endpoints on the outside if you want and have the SBC/SM mutual TLS authenticate.
You and I aren't the first people to gripe that the SBC doesn't do OCSP to avoid loading an explicit list of revoked certs.
So, yeah, without mutual TLS on the outside, all the endpoints need to do is trust your root CA. Your root CA cert is not private or under your control. If I go to and get a cert for yourinternalwebsite that chains up to the rootCA, I can take that cert, pop it in my device and get a login prompt.
Managing CRLs on the SBC and enforcing mutual TLS on his outside is what they want. Even on the SM inside, that's just going to make the SBC-->SM mutual TLS. You could have TCP endpoints on the outside if you want and have the SBC/SM mutual TLS authenticate.
You and I aren't the first people to gripe that the SBC doesn't do OCSP to avoid loading an explicit list of revoked certs.
- Thread starter
- #74
so my assumptions as I understand.. When you mean mutual auth on the outside that's the setting requiring peer verfication? and since the ios device didn't provide an identity cert because the trace shows () I get a failure? My company website, per your example uses a verisign cert. The SBC is using our enterprise PKI. And w/o mutual auth on the SBC, even if the hardphones have identity certs the CRL is useless?
Is there a way to force mutual only for deskphones and leave the ios as is?
Is there a way to force mutual only for deskphones and leave the ios as is?
mutual auth, peer verification, yes - same thing. To say, the SBC being configured to offer a cert your devices trust and demand the devices provide a cert the SBC trusts.
You can have 1 cert for "ios devices" but lose the ability to revoke it on a device by device basis.
You could just as well offer up a verisign cert to the devices from the SBC - that part doesn't matter - you're just asking the devices to trust your SBC, whether that's through your enterprise PKI or public, it's not entirely relevant as anyone can wireshark a TLS handshake to your SBC, grab your CA cert and decide to trust it.
Somewhere in the profiles/end point policy groups/endpoint flows you can define which CAs you trust for peer validation and you should be able to break out different "security" and "signaling" rules on a per-user agent basis. So in short, Avaya One-X Desk* can do mutual TLS and need the phone to present a cert chaining up to your enterprise CA and iOS devices won't require that.
Or, in a more practical sense globally, you may have internet facing TLS SIP trunks from a carrier. You can peer verify for them and trust a public Verisign CA for that SIP trunk and offer them a verisign cert for your SBC. You can SIP trunk across your WAN to a company you just acquired and have a peer validated TLS sip trunk where you require an enterprise CA-signed cert for that one. You can have remote workers need a peer validated enterprise CA cert to come on in. Then you can set up the HTTPS reverse proxy to Aura Conferencing so your people can send out collaboration invites to outsiders and share desktops and stuff and have no peer verification for those outsiders coming in, but have a verisign cert for on the SBC. That conferencing case is one where you're trying to prove your interface's trustworthiness to John Q Public and you don't need anything back from him for him to participate in a screen sharing session. You just want to send him a valid cert so he gets the little green lock in his browser so firefox allows the website to acquire his webcam and microphone.
So yes, you can peel it out!
You can have 1 cert for "ios devices" but lose the ability to revoke it on a device by device basis.
You could just as well offer up a verisign cert to the devices from the SBC - that part doesn't matter - you're just asking the devices to trust your SBC, whether that's through your enterprise PKI or public, it's not entirely relevant as anyone can wireshark a TLS handshake to your SBC, grab your CA cert and decide to trust it.
Somewhere in the profiles/end point policy groups/endpoint flows you can define which CAs you trust for peer validation and you should be able to break out different "security" and "signaling" rules on a per-user agent basis. So in short, Avaya One-X Desk* can do mutual TLS and need the phone to present a cert chaining up to your enterprise CA and iOS devices won't require that.
Or, in a more practical sense globally, you may have internet facing TLS SIP trunks from a carrier. You can peer verify for them and trust a public Verisign CA for that SIP trunk and offer them a verisign cert for your SBC. You can SIP trunk across your WAN to a company you just acquired and have a peer validated TLS sip trunk where you require an enterprise CA-signed cert for that one. You can have remote workers need a peer validated enterprise CA cert to come on in. Then you can set up the HTTPS reverse proxy to Aura Conferencing so your people can send out collaboration invites to outsiders and share desktops and stuff and have no peer verification for those outsiders coming in, but have a verisign cert for on the SBC. That conferencing case is one where you're trying to prove your interface's trustworthiness to John Q Public and you don't need anything back from him for him to participate in a screen sharing session. You just want to send him a valid cert so he gets the little green lock in his browser so firefox allows the website to acquire his webcam and microphone.
So yes, you can peel it out!
- Thread starter
- #76
What would be the cause of a successful registration, a fully connected call between the endpoint and both internal/external endpoints and no audio? Considering our network folks do not see drops for the udp port range on the FW, which I can't believe. If the device is on the corporate wireless the 2 way audio is normal. What is strange is we are not doing anything where we register directly at ASM internally, so this shouldn't work regardless of where the endpoint is.
Look at the SDP on the outside signaling. If the "public IP" of the SBC isn't in the network config, it's possible the endpoint outside is being told to send audio to 10.x.x.x
The SBC requires a remote worker to send audio first to know how to punch back through his NAT (like your 192.168.x.x at home), so not having that public IP in there would be the first place I'd look.
The SBC requires a remote worker to send audio first to know how to punch back through his NAT (like your 192.168.x.x at home), so not having that public IP in there would be the first place I'd look.
- Thread starter
- #78
Yea, those publics are in the network. When running the tracSBC I get success registration and when I attempt a call it goes through and connects just fine. I see the public IP the endpoint had at the top of the trace, but in the invite from the endpoint to the SBC's .. in the SDP body it has the 10.x IP in the C field. what the blazing heck with this thing..
Scratch my previous comment about audio working both ways on the internal WiFi via the SBC. The registration goes through fine, but I get nothing in the trace once I make and connect the call, which has 2 way audio. Assuming that successful media traffic is bypassing the SBC, since it's on the internal network.
Scratch my previous comment about audio working both ways on the internal WiFi via the SBC. The registration goes through fine, but I get nothing in the trace once I make and connect the call, which has 2 way audio. Assuming that successful media traffic is bypassing the SBC, since it's on the internal network.
Registration is one thing RTP is another. SIP uses both ports and IP's for phone traffic. What network guys need to know is SIP cannot change ports while establishing a call. If ports change than you will loss audio. In trunking with UDP you have this thing call ALG that will get in the way and cause these issues if not configured correctly (turn off in one firewall model, but may need it on another model). I don't think this is the issue, but you should do a PCAP and listen to audio and view ports.
So this 10.x c= line is on the public internet? Try on home wifi and mobile. Some mobile carriers internationally suck and don't give you a public IP for your device so you're behind their NAT.
As far as I've known, your device should be smart enough to figure out it's public IP and pop that in the c= line. I'd try at least a couple of different networks to confirm the theory. Where's the 10. IP from anyway? Not your home wifi I'm pretty sure.
As far as I've known, your device should be smart enough to figure out it's public IP and pop that in the c= line. I'd try at least a couple of different networks to confirm the theory. Where's the 10. IP from anyway? Not your home wifi I'm pretty sure.
- Status
Similar threads
