IX Workplace iOS

[wpetilli]

We have a set of folks that use the IX Workplace iOS app and some random folks are now getting a voip certificate error. Myself and a few others are working fine and I'm not finding the common denominator.

latest version of iOS and IX Workplace
Our MDM provides the device with our root and subca certs
the app gets setup via a 46xx.settings file and is set for SET TRUSTCERTS ""
The SBC is setup for server auth

When running a traceSBC from my device the TLS handshake completes and follows through with all the subscribes and success.
This non working device just shows a page long back and forth of TLS handshake and just stops. No fatal cert error or any of those messages.
Had the user remove the app, re-install and has the same issue.

SMGR / SM are on 7.0.1

I'm going to open a ticket, but I'm not seeing what the issue is with these. Did a stare and compare of the non working device to mine and nothing seems off. Anyone see this before and/or have somewhere to check?

 

[kyle555]

client logs will tell the story.

There's the PSN about iOS not wanting certs valid for 2 years if they're not "stapled" or kinda co-signed by other public CAs

Quick'n'dirty - I use Let's Encrypt

So, I got a Windows machine behind the SBC, I port forward port 80, turn on IIS, run the "Certify the web" app.

I can add FQDNs in the certify the web app that will be SANs in the cert.

Go reverse proxy port 80 for each relevant IP to your IIS and the certify the web app drives IIS to answer challenges and when it's done, in IIS Manager/Server Certs, you've got a public cert. use openssl to extract key/pem and give it to the SBC.

Every iPhone is happy.

I got a subscription to BrowserStack.com - $50/month and you can grab any iPhone or Android you want - they're not emulated - they're real devices.

I go download IX Workplace from the app store, autoconfigure via the Spaces pointer to AADS and that's how I have a BlackBerry but still managed to test that I got Apple Push Notifications working properly.

Otherwise, what's the validity period of your cert?

 

[wpetilli]

Since we use the SET TRUSTCERTS "" doesn't that tell the device to not use the app trust store and that of the device? Our MDM provides all the relevant certs for the device. When the phone attempts the connection, it hits the SBC and the SBC presents its cert, which the root and subca are the same as what's in the device trust store. On the SBC We don't have the server profile doing peer verification. I would have thought the devices see the SBC cert and since it trusts the root and subca, it allows it to make the negotiation. I don't see the device in the trace doing anything with an identity cert like I do the deskphones where we do have peer verification. The root and subca certs are valid till 2026 or something way out like that.

 

[wpetilli]

when I open up the logs from the non working device, I found these messages. Just not sure what they mean and what I need to do about it.

2020-09-03 10:40:36.167 D [csdkloop] [CSDK] CAvayaSecurityPolicy::IsKeyLengthValid Configured KeyLength: 1024 Public KeyLength: 4096
2020-09-03 10:40:36.167 I [csdkloop] [CSDK] [SECURITY] INFO CAppleCertificateProvider::CreateSecTrustSecurityPolicies():760 Overriding platform's hostname validation behavior via SDK's hostname validation.
2020-09-03 10:40:36.167 D [csdkloop] [CSDK] CAppleCertificateProvider::ConfigureTrust():1469
2020-09-03 10:40:36.167 I [csdkloop] [CSDK] [SECURITY] INFO CAppleCertificateProvider::ConfigureTrust():1513 Private trust store has been disabled, but the trust store mode has been set to "privateAndSystem", using system trust store.
2020-09-03 10:40:36.172 D [main] [CSDK] CCallbackManager:rocessNext(): Invoking IContactServiceReturnResultListener::OnContactsAdded()
2020-09-03 10:40:36.172 D [923204] [CSDK] CAppleCertificateProvider:perator()():1612 trust.Get()[0x28367e2e0] trustRef[0x28367e2e0] trustResult[5]
2020-09-03 10:40:36.172 D [923204] [CSDK] CAppleCertificateProvider::ConvertSecTrustResultToCertificateValidationResult():1376 Overall Trust Result = 5
2020-09-03 10:40:36.172 W [923204] [CSDK] [SECURITY] WARN Certificate Validation Error Code = eCERT_VALIDATION_ERR_UNTRUSTED
2020-09-03 10:40:36.172 D [923204] [CSDK] CAppleCertificateProvider::VerifyCertificateChainUsingOpenSSL():654 Additional certificate validation information (
{
type = error;
value = "Unable to build chain to root certificate.";

 

[kyle555]

OK. Browsers usually just check the server cert and the root CA cert.

Can you go

https://yourSM:5061

in a browser, do a TLS handshake, view the cert, and see if each cert in the chain is in there?

What certs are put into your iPhone?

I've seen "intermediate.pem" as 1 trusted cert and root.pem as another, but if you make a txt file of both, the intermediate first, paste the root after, all in 1 file it makes things happy.

I did that with Let's Encrypt's chain as the "ca" cert the SBC trusts. It's actually a text file with the pasted ----BEGIN CERTIFICATE---- and ------END CERTIFICATE-------- one after the other.

Maybe if the iPhone had a single trust cert with the whole chain?

 

[wpetilli]

Maybe but my device has the same 2 separate certs and it works fine.

 

[kyle555]

is the root ca cert 1024/sha1?

 

[jimbojimbo]

Please keep in mind, the latest release of iOS and Android follow the CA Browser forum recommendations and will not honor certificates with a validity period of more than 825 days (27 months). The client also requires you either provide the SIP Domain in the Subject Alternate Names or set TLSSRVRID and TLSSERVERID to 0 to prevent host validation. There are also a couple of settings relative to trusting the local OS trustore. Since you were not specific on who the CA authority is or the validation depth it is difficult to provide an accurate answer. You can provide the certificates to an iOS device however, after they are loaded you still need to go in and "trust" them (settings>about>certificate trust settings) by setting Enable Full Trust for Root Certificates on each one imported. A traceSBC should give you a good indication of what the issue is. Just enable SIP and TLS for the trace.

 

[wpetilli]

@Kyle - no it's not 1024/SHA1
@Jimbo - The installed certificate we applied on the SBC is only a 2 year cert
- The cert the device gets from our MDM is also 2 year
- The CA certs are alot longer.
- The 46xx file has: SETTRUSTCERTS "" Which I take to mean to use the device trust store

Avaya indicated to "add subCA cert. and root CA cert. to cert. file and then SBC will send the complete cert. chain out. Then IOS APP will not need to create the chain to root cert. and only needs to verify the cert. with root CA cert. in IOS trust store."

Still doesn't explain why some users, who are all on the same iOS version and IX version are working and others get this VOIP Cert error. The same MDM manages all of these devices and they all have the same certificates in the device trust store (identity cert is unique).

 

[kyle555]

See if you can enable USB debug mode on the iPhone.

If you can get your company to swing it, get a subscription to BrowserStack.com AppLive product. It's for mobile developers where they run their aps through unit tests of things.

There's no legit iPhone emulator beyond what XCode tools has, but these guys let you grab any Android or iPhone and run it in a browser with a debug.

Side-note - was helping a buddy debug his app and it seems iOS 13.3 attempts a TLS 1.3 handshake and while testing the certificate with ssllabs.com, it said it supported SCT for certificate transparency, but the debug of the iPhone said it didn't.

Our working theory is that iOS 13.3 is more strict about TLS 1.3 and doesn't try to fallback to 1.2. But other people can't reproduce on 13.9 - and he hasn't got their trace of it working either.