Trying to set up a user with IX Workplace on their iPhone over VPN to be able to receive their calls. However after setting up their extension they get a red triangle with ! saying VOIP service limited. I tested the same exact settings on an Android phone and it worked flawlessly. Is there a specific setting for the iPhone I need to set? The user is on an iPhone 8 Plus, iOS version 13.2. It seems to work fine when on WiFi and not connected to the VPN, which leads me to believe the VPN is at fault, but both iPhone and Android tests used the same VPN client (Sonicwall Mobile Connect)
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!
IX Workplace VOIP service limited on iPhone 2
- Thread starter Shad0wguy
- Start date
How did you generate the certificate? Apple recently applied new certificate rules. One part is that the maximum certificate lifetime must not exceed 825 days, while Server Edition/Application Server by default generates certificates that are valid for 2555 days.
See:
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
See:
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
I have exactly the same problem.
On Android 9, the certificate in .pem passes, I can connect.
On iPhone7, iOS13, the certificate is not validated.
Have you validated the certificate as a configuration profile then in settings> information> settings of the certificates?
On Android 9, the certificate in .pem passes, I can connect.
On iPhone7, iOS13, the certificate is not validated.
Have you validated the certificate as a configuration profile then in settings> information> settings of the certificates?
IPO CA up to 11.0.4.0 (I guess) creates certificates that don't meet the needs of Apple iOS 13.
Their lifetime is to long (but we can adjust this) and the extended key usage (EKU) field doesn't contain "Server Authentication" (and we can't adjust this).
A 11.0.4.1 CA should work.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Their lifetime is to long (but we can adjust this) and the extended key usage (EKU) field doesn't contain "Server Authentication" (and we can't adjust this).
A 11.0.4.1 CA should work.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
As if the use of these certificates was not complicated enough ...
We didn't need the manufacturers of mobile phones to do it
According to the derfloh's document found :
[ul]
[li]Compliance with Android Q, iOS 13 and macOS 10.15[/li]
[ul]
[li]TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits :: we can choose the Public Key Algorithm[/li]
[li]TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm :: Knowing that the SHA-256 is part of the SHA-2 family, it should work[/li]
[li]TLS server certificates must present the DNS name of the serverin the Subject Alternative Name extension of the certificate :: We could already do it[/li]
[/ul]
[li]Compliance with TLS server certificates issued after July 1, 2019[/li]
[ul]
[li]TLS server certificates must have a validity period of 825 days or fewer :: we can adjust their lifetime[/li]
[li]TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID :: don't found anything on this point[/li]
[/ul]
[/ul]
We didn't need the manufacturers of mobile phones to do it
According to the derfloh's document found :
[ul]
[li]Compliance with Android Q, iOS 13 and macOS 10.15[/li]
[ul]
[li]TLS server certificates and issuing CAs using RSA keys must use key sizes greater than or equal to 2048 bits :: we can choose the Public Key Algorithm[/li]
[li]TLS server certificates and issuing CAs must use a hash algorithm from the SHA-2 family in the signature algorithm :: Knowing that the SHA-256 is part of the SHA-2 family, it should work[/li]
[li]TLS server certificates must present the DNS name of the serverin the Subject Alternative Name extension of the certificate :: We could already do it[/li]
[/ul]
[li]Compliance with TLS server certificates issued after July 1, 2019[/li]
[ul]
[li]TLS server certificates must have a validity period of 825 days or fewer :: we can adjust their lifetime[/li]
[li]TLS server certificates must contain an ExtendedKeyUsage (EKU) extension containing the id-kp-serverAuth OID :: don't found anything on this point[/li]
[/ul]
[/ul]
@bdtp
I figured out that with the latest IPO the certificate fits. With earlier releases (I guess up to 11.0.4.0) it doesn't fit.
I'll try to find out what we have to adjust to make it work.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
I figured out that with the latest IPO the certificate fits. With earlier releases (I guess up to 11.0.4.0) it doesn't fit.
I'll try to find out what we have to adjust to make it work.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Sorry for the for the confusion. It's the same here.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Not seen this using inbuild certs, as we use public certs where ever possible (Go Daddy UCC etc), but we did get this issue on containers.
If the issue is the new reqs of iOS13/Androijd Q, then it is only certs generated after 01/07/2019 and that are more than 850 ish days until expiry. everything else is OK with the cert.
11.0.4 had an issue and created certs with a lifespan of 2500+ days, but the iOS and Android only don't like this if it was made after 01/07/2019. I guess this is to allow backward compatibility and give people time to change thier cert.
For the containers we saw the issue, we upgraded to 11.0.5 and then had to get Avaya to regenerate the certs for us, as we cannot.
So if you are using inbuilt certs, make sure you are on 11.0.4.1 and regenerate your cert. Or buy a UCC for your FQDN. Hopefully, you will be fine after this.
IF its none of the above cert problem you have, then I think the VPN connection is probably the issue. Look into getting an SBC to make life simpler (but more expensive!!). If you have SIP Tranformations on your Sonicwall, this will cause problmes, even though you are using a VPN. Seen this issue before.
Jamie Green
[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer
If the issue is the new reqs of iOS13/Androijd Q, then it is only certs generated after 01/07/2019 and that are more than 850 ish days until expiry. everything else is OK with the cert.
11.0.4 had an issue and created certs with a lifespan of 2500+ days, but the iOS and Android only don't like this if it was made after 01/07/2019. I guess this is to allow backward compatibility and give people time to change thier cert.
For the containers we saw the issue, we upgraded to 11.0.5 and then had to get Avaya to regenerate the certs for us, as we cannot.
So if you are using inbuilt certs, make sure you are on 11.0.4.1 and regenerate your cert. Or buy a UCC for your FQDN. Hopefully, you will be fine after this.
IF its none of the above cert problem you have, then I think the VPN connection is probably the issue. Look into getting an SBC to make life simpler (but more expensive!!). If you have SIP Tranformations on your Sonicwall, this will cause problmes, even though you are using a VPN. Seen this issue before.
Jamie Green
[bold]A[/bold]vaya [bold]R[/bold]egistered [bold]S[/bold]pecialist [bold]E[/bold]ngineer
I created certificates with 11.0.4.1 Server Edition CA, but it is not trusted by an iPhone. SANs are OK, validity is OK, EKU is OK, key lengths are OK, algorithms are OK.
I wasn't able to figure out what the problem is.
I already created certificates with a windows ca and all is fine.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
I wasn't able to figure out what the problem is.
I already created certificates with a windows ca and all is fine.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Since iOS 13 you don't just have to install the root certificate. You also define it as trustful under settings - common - info - certificate trust (or similar) where you have to enable the trust.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
See
If using the IP Office self-signed certs then you need to be on the latest service packs (and after regenrarting, go through the pain of defaulting any existing phones and apps that were using the previous cert - so the fix for iOS will affect non-iOS users also).
Stuck in a never ending cycle of file copying.
If using the IP Office self-signed certs then you need to be on the latest service packs (and after regenrarting, go through the pain of defaulting any existing phones and apps that were using the previous cert - so the fix for iOS will affect non-iOS users also).
Stuck in a never ending cycle of file copying.
Yeah... Got all the new rules but didn't figure out, that I have to trust a new root CA manually through the settings after installation.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
-
2
- Thread starter
- #14
Open certificate on iPhone.
Go into settings - common - profiles and choose to install the certificate.
Go into settings - common - certificate trust (at the bottom of the common settings page) and enable the certificate to be trustful.
Since my iPhone is in German, I tried to translate the settings to English for you and apologize if the translations are wrong.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Go into settings - common - profiles and choose to install the certificate.
Go into settings - common - certificate trust (at the bottom of the common settings page) and enable the certificate to be trustful.
Since my iPhone is in German, I tried to translate the settings to English for you and apologize if the translations are wrong.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Thanks deffloh, but my problem is elsewhere
Subject Name: name.ipo.test
Subject Alternative Name(s): name.ipo.test, IP:x.x.x.x, IP:192.168.43.1
Duration (days): 824
Public Key Algorithm: RSA-2048
Secure Hash Algorithm: SHA-256
Regeneration, waiting for system to reboot, then download cert.crt and put in in the iPhone.
When installing in the iPhone, it says "The authenticity of name.ipo.test can not be verified". I install, but it isn't displaying in settings - about - certificate trust ...
Subject Name: name.ipo.test
Subject Alternative Name(s): name.ipo.test, IP:x.x.x.x, IP:192.168.43.1
Duration (days): 824
Public Key Algorithm: RSA-2048
Secure Hash Algorithm: SHA-256
Regeneration, waiting for system to reboot, then download cert.crt and put in in the iPhone.
When installing in the iPhone, it says "The authenticity of name.ipo.test can not be verified". I install, but it isn't displaying in settings - about - certificate trust ...
You need the server edition root cert.
Open WebControl (Port 7071) and go into settings. Scroll down to the certificate area and download the root cert using the button "Download (PEM)". If you do that with your iPhone you now have to go into profiles and cert trust to do the mentioned steps.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
Open WebControl (Port 7071) and go into settings. Scroll down to the certificate area and download the root cert using the button "Download (PEM)". If you do that with your iPhone you now have to go into profiles and cert trust to do the mentioned steps.
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
I have regenerated a cert.
After reboot, I go back on 7071,
- click on downloadRootCA button named "Download (PEM-encoded)". I get the root-ca.pem
- then, click on downloadIdCert button named "Download (PEM-encoded)". I get the cert.pem
If I understand the root-ca.pem is needed to validate the cert.pem
I upload these files on my iPhone, install root-ca.pem, I can see it in settings - about - certificate trust and activate it.
But, while installing the cert.pem, I can't see it in settings - about - certificate trust and so I can't activate it.
[edit] root-ca certificate is still valid until 2029 while cert certificate is valid for 825 days
After reboot, I go back on 7071,
- click on downloadRootCA button named "Download (PEM-encoded)". I get the root-ca.pem
- then, click on downloadIdCert button named "Download (PEM-encoded)". I get the cert.pem
If I understand the root-ca.pem is needed to validate the cert.pem
I upload these files on my iPhone, install root-ca.pem, I can see it in settings - about - certificate trust and activate it.
But, while installing the cert.pem, I can't see it in settings - about - certificate trust and so I can't activate it.
[edit] root-ca certificate is still valid until 2029 while cert certificate is valid for 825 days
The iPhone doesn't need to know about the server cert (cert.pem).
It is used by the server to identify itself and iPhone trust the server as long as the SANs fit and as long as iPhone trusts the issuing CA (rootCA.pem).
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
It is used by the server to identify itself and iPhone trust the server as long as the SANs fit and as long as iPhone trusts the issuing CA (rootCA.pem).
IP Office remote service Fixed price SIP trunk configuration: CLI based cale blocking: SCN fallback over PSTN:
- Status