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
- #101
hmmmm.. well 2 things.. I'm preparing for a SSCA cert and wanted to see traces of my own stuff other than the material. I was on the regular cell network and was running a traceSBC. I logged into the client, let it fully register and then stopped the trace. While looking through the trace I'm unable to find the original registration message from the device to the SBC B1 with CSeq: 1. I see the certificate exchange messages and then a 'Trying' from the SBC back to the device, then the REG, Unauth from the SBC A1 to SM. The registration packet I'm looking at is the re-register from the client to B1. That's where I'm seeing that 10.x.x.x appended. I'm not seeing that IP in the Reg messages from the internal to SM and back, so I'm assuming this is something you mentioned that the cell provider is doing and isolated at the SBC. Not an issue, because everything is working, but annoying cause I don't know. The original Reg packet is a mystery that I can't find that.
Odd. Are you a single HA pair or multiple? Is it possible DNS roundrobin across multiple SBC pairs is in play?
Logs from a Windows client, or a wireshark pcapping a WinEquinox would prove whether it's taking the same path.
If you got 2 HA pairs, say from a Windows PC you edited the hosts file for sbc.yourcompany.com to point to a single IP.
Logs from a Windows client, or a wireshark pcapping a WinEquinox would prove whether it's taking the same path.
If you got 2 HA pairs, say from a Windows PC you edited the hosts file for sbc.yourcompany.com to point to a single IP.
- Thread starter
- #103
Glad this thread didn't close. I'm working with the 9611G deskphone for remote deployment and having an issue. I've made a bunch of changes to the SBC to use mutual auth for these phones and I'm getting a successful registration. I'm able to go off hook and dial, but as soon as the far end phone rings there's a fast busy and hangup. The traces on the SBC show ASM returning 484 address incompletes, followed by 488 Not Acceptable Here. In the body of the 488 it shows 'Media Format Not Available'. At the same time the CM trace on the SIP TG TAC between it and ASM says 'Codec Mismatch'. Sounds simple enough, but if I connect this phone internally, it still comes in via the SBC and then registers with an IP on the internal network. When I repeat the same call everything works fine, so I'm not clear where the codec has to be corrected. The phone takes the same path when calling the destination, which is confusing.
IP-network-map ties subnet to IP-network-region, where it is defined to use certain codec sets to other regions.
Whatever happens between the phone and SBC is one thing, whatever the SBC signals for RTP inside is another. The SBC would need a media rule internally to pitch/catch something mutually agreeable with the PBX.
Generally having your ip-codec-sets in CM have a few encryption types plus none as the last choice is enough.
To get SRTP, I believe you need to "enforce SIPS URI" in the route pattern from CM to SM. That's to say if you have a codec set and a phone's config both only allow SRTP, you probably won't ever get anything if that SIPS setting in a route is 'no'. So, if the SBC has a media rule for only SRTP, and it's inviting a SIP endpoint inside that has a terminating app sequence thru a route without "enforce sips uri", then that could be a rational explanation for your problem.
Compare the remote phone's SDP into the SBC, from the SBC to SM, to CM, and what CM does with that outwards to the destination to see if there's something inconsistent.
Whatever happens between the phone and SBC is one thing, whatever the SBC signals for RTP inside is another. The SBC would need a media rule internally to pitch/catch something mutually agreeable with the PBX.
Generally having your ip-codec-sets in CM have a few encryption types plus none as the last choice is enough.
To get SRTP, I believe you need to "enforce SIPS URI" in the route pattern from CM to SM. That's to say if you have a codec set and a phone's config both only allow SRTP, you probably won't ever get anything if that SIPS setting in a route is 'no'. So, if the SBC has a media rule for only SRTP, and it's inviting a SIP endpoint inside that has a terminating app sequence thru a route without "enforce sips uri", then that could be a rational explanation for your problem.
Compare the remote phone's SDP into the SBC, from the SBC to SM, to CM, and what CM does with that outwards to the destination to see if there's something inconsistent.
- Thread starter
- #105
Our A/D team had finally built out a new SCEP policy to deploy SHA2 certs to the 9611 phones I want to deploy remotely. So, I went back to do the work on the SBC that would do mutual auth with the hardphones and server auth with the iphones. Hence yesterday's issue and typically SBC pain. In any event the ip-codec assigned to NR1 had matching codecs across the other regions, but didn't have any options other than 'none' in the media encryption area. Adding the 1-srtp and 2-srtp and 3 none fixed it. I guess for once the response codes and denial event actually stated what the problem actually was.
Final piece is to test the CRL on the SBC and get the certs to autorenew once deployed in the field. Have to figure out how to test that piece, since the certs that get cut are 2 or 3 years.
Final piece is to test the CRL on the SBC and get the certs to autorenew once deployed in the field. Have to figure out how to test that piece, since the certs that get cut are 2 or 3 years.
- Thread starter
- #107
Now I am having issues with the CRL. The certificate that was provided to the phone was revoked and I was provided a CRL in .pem format. I uploaded this to the SBC and applied it to the server profile. Rebooted the phone and the phone was unable to get back in, which was great. I factory reset the phone and re-provisioned it and it was given a new certificate. The phone was still unable to get in via the SBC. I took a totally different phone and provisioned it and that wouldn't pass through the SBC either. After removing the CRL the phones worked fine again. I guess a few questions.. where do you apply the CRL.. client or server profile? And are there specific requirements for the CRL on what it looks at during the inspection? In viewing the CRL it just has the serial numbers of the revoked certificates in it. I'd understand if it was the mac address of the endpoint.
Presumably the server profile. I'd say phone-->B1 the sbc is a server. A1-->SM the SBC is the client.
I'd imagine the CRL is literally just the entirety of the pems -----BEGIN CERT HERE------- asdjwjfiwejierjo ------END CERT HERE--------- cat'ed into 1 big file.
Here's an absolutely ridiculous idea. Change the SCEP profile of the phone to use serial number instead of MAC, or vice-versa. Maybe the SBC is categorically stupid and considers and CN= in a cert in a CRL to make the SBC reject that CN.
As in, you can't issue a cert to CN=9611SERIAL123456, then revoke it, then issue another to the same CN despite it being a different certificate.
That's not how CRLs should work at all. But with the SBC and certs...nothing would surprise me.
Open a case and traceSBC the TLS handshake once you know your phone has a new cert that isn't in the CRL...
Last thought: maybe the phone's cert issued via SCEP is lazy and has the CA cert+ the phone cert to provide the validation chain. Maybe by "revoking" the phone's cert you inadvertently "revoked" the whole chain including the CA for any other phone that has a cert signed by the same CA. It's the only way I could think of where it's "working as designed" and you did "something wrong". I guess the test would be use SCEP to get a cert from some other CA and try again for 2 phones.
Or, look at the CRL. Sometimes people do something like this:
Basically, to have the CA cert and the device cert people will "cat ca.cert signed.cert >phone.cert" and by revoking "phone.cert" you inadvertently revoked "ca.cert" for everyone who has a cert signed by that CA.
I'm just guessing. but check your CRL - if you find the CA cert in there anywhere, you have your answer
I'd imagine the CRL is literally just the entirety of the pems -----BEGIN CERT HERE------- asdjwjfiwejierjo ------END CERT HERE--------- cat'ed into 1 big file.
Here's an absolutely ridiculous idea. Change the SCEP profile of the phone to use serial number instead of MAC, or vice-versa. Maybe the SBC is categorically stupid and considers and CN= in a cert in a CRL to make the SBC reject that CN.
As in, you can't issue a cert to CN=9611SERIAL123456, then revoke it, then issue another to the same CN despite it being a different certificate.
That's not how CRLs should work at all. But with the SBC and certs...nothing would surprise me.
Open a case and traceSBC the TLS handshake once you know your phone has a new cert that isn't in the CRL...
Last thought: maybe the phone's cert issued via SCEP is lazy and has the CA cert+ the phone cert to provide the validation chain. Maybe by "revoking" the phone's cert you inadvertently "revoked" the whole chain including the CA for any other phone that has a cert signed by the same CA. It's the only way I could think of where it's "working as designed" and you did "something wrong". I guess the test would be use SCEP to get a cert from some other CA and try again for 2 phones.
Or, look at the CRL. Sometimes people do something like this:
Basically, to have the CA cert and the device cert people will "cat ca.cert signed.cert >phone.cert" and by revoking "phone.cert" you inadvertently revoked "ca.cert" for everyone who has a cert signed by that CA.
I'm just guessing. but check your CRL - if you find the CA cert in there anywhere, you have your answer
- Thread starter
- #109
Opened a case and provided them with the logs/traces they requested and so far they are flagging that the SBC doesn't seem to be accepting the CRL file where the certificatecipher is 'none' and are requesting to regenerate with cipher default or custom. And that the date of the CRL is expired, which kind of doesn't make sense. Who cares when the CRL was generated and installed? If that's an actual issue then they're basically saying you need to upload a new CRL every day, which is insane.
Well, I know everytime in SMGR I need to change a cert cause I did something wrong, I have to expire the previous one. That makes the CRL that existed at the time expired and SMGR's CA has a list of the CRLs including the expired ones. I presume that, like certificates, the CRLs also have an expiration date. Either your CA is being extra secure by making sure you have a new one all the time and expiring every day, or the SBC is being goofy.
- Thread starter
- #111
Not sure this was the only way to do this, but it did work. In addition to the CRL cert we also uploaded the CRL Root crt and that fixed the issue. The date in the CRL cert did not matter, so it doesn't need to be updated daily.
For 9611 phones using SCEP to obtain certs.. has anyone been able to get the certificate renewal piece working? In the settings file I set the certrenew to 1 and waited the alloted time and didn't seem like anything happened. I assume the SBC would require FW rules to access the server that provides the certificates, which was done.
For 9611 phones using SCEP to obtain certs.. has anyone been able to get the certificate renewal piece working? In the settings file I set the certrenew to 1 and waited the alloted time and didn't seem like anything happened. I assume the SBC would require FW rules to access the server that provides the certificates, which was done.
As far as I can tell, it looks like all that matters is the URL - which is very important - but it's not like a SCEP proxy is going to need to masquerade and pretend to the the CA to your 96xx and pretend to be the 96xx towards the CA.
It seems that there are established ways to set up a SCEP proxy.
The SBC seems to address it in an overly simplified way with just a relay service. I'm not sure it would work in every circumstance or with every flavor of SCEP. If something about that SCEP request can be set to have your IP in it, it could get lost.
Anyway, i'd guess the SBC can do it in some cases and if it's more complicated, then it couldn't.
- Thread starter
- #113
I've been testing the use of a CRL on the SBC, but there are a few observations that are causing pain
The SBC doesn't permit polling a URL (like every other normal system) and requires an actual CRL certificate upload. It's an annoyance, but we've done that and it does work; However, the expiration date of the CRL is what is an issue now. The CRL's are generated with very short date spans and once the date expires the SBC rejects all registrations... valid cert or not. Uploading a new CRL ever other day is not sustainable. Does anyone know if there's a way for the SBC to ignore the date during the revocation check?
The SBC doesn't permit polling a URL (like every other normal system) and requires an actual CRL certificate upload. It's an annoyance, but we've done that and it does work; However, the expiration date of the CRL is what is an issue now. The CRL's are generated with very short date spans and once the date expires the SBC rejects all registrations... valid cert or not. Uploading a new CRL ever other day is not sustainable. Does anyone know if there's a way for the SBC to ignore the date during the revocation check?
jimbojimbo
Vendor
If you are talking about the System Manager CRL you can modify the CRL lifespan in the System Manager CA (assuming it is not a SubCA). Doesn't "fix" the issue but will allow longer duration for CRL expiration. I set mine for 1yr. Just need to remember to create and upload a new one if you revoke a cert.
- Thread starter
- #116
this is going back a ways...it's been a long thread!
I thought you were ultimately doing SCEP from the phones through to a SCEP server that was not SMGR. If so, the CRL needed is the one from that CA. If it's just SMGR, then jimbo is most likely right that it can be tweaked
I thought you were ultimately doing SCEP from the phones through to a SCEP server that was not SMGR. If so, the CRL needed is the one from that CA. If it's just SMGR, then jimbo is most likely right that it can be tweaked
- Thread starter
- #118
- Status
Similar threads