Link to home
Create AccountLog in
Avatar of Frosty555
Frosty555Flag for Canada

asked on

iPhone Exchange account doesn't work when on the Wifi, works on 3G

We have an Exchange server on our network which uses a split-dns environment. That is, we use:

"mail.ourcompany.com"  -   resolves to the internal IP of the exchange server when on the LAN, and it resolves to the external IP of our router when connecting from the Internet.

It took a bit of work to get the certificate working, but I changed all the internal/external URL settings to get Outlook working both inside the lan, and outside the lan, without complaining about certificate issues.

Now we're facing a problem:

iPhones can't add the Exchange Account when they are on the LAN connected to Wifi. They get an error message about not being able to connect to the server.

If they go onto 3G, they can add the EXchange account fine. AND - when they come back onto the WiFi after adding the account for the first time, mail continues to flow and everything works fine.

It's just the initial set up that doesn't work. Also, autodiscover doesn't work either - the iPhone prompts them for their username and server name when try try to set it up on the WiFi.

Any idea what could be wrong?

Exchange 2013 on Windows Server 2012
Avatar of Patrick Bogers
Patrick Bogers
Flag of Netherlands image

Hi,

Seems like the iPhone needs the external bound SSL certificate to verify the server. Once installed it can connect from you local domain because the trust relation has been set.
Could this be the case?
ASKER CERTIFIED SOLUTION
Avatar of Simon Butler (Sembee)
Simon Butler (Sembee)
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
Why did you have some many problems with the cert? If you specified all the subject alternative names correctly you wouldn't have any problems at all.

For example on all the certs that I create I always use these names:

autodiscover.domain.com
mail.domain.com
domain.com
servername (internal name)
servername.domain.local (FQDN)

Then all you have to do it create a Forward Lookup zone on your DNS server for domain.com that resolves the names to the internal IP addresses. I just recently did this for about 4 clients and they have no problems like you are describing. If you recently got the cert you should be able to call them and get it reissued with the correct Subject Alternative Names. Fix the cert and create the Forward Lookup Zone for yourdomain.com and everything will work just fine.
Avatar of Frosty555

ASKER

XKincaidx, recently SSL certificates cannot include internal hostnames as SANs anymore. So, because of this I had to do some fiddling with the URLs and some settings in Active Directory so that only the external hostnames were used, inside the network and outside..

I posted a question about it earlier I can go back and find it or you can probably find it in my history.

Sembee I didn't know that tool existed in Outlook. I'll try it out in a test machine and get back whether it sheds any light on the situation
I just made three a few weeks ago Comodo and everything went fine with the internal names. Maybe it is just your provider or the rules are changing.

You should still be able to create a Forward Lookup zone to point to your servers. What names did you create A records for?
The rules in general are changing and all SSL providers are making the change.
The rules actually come in to effect from November of 2015, so any certificate that expires after that date will need to conform. Therefore if you just put in a certificate that expires before that date then you would be fine.

However it is better to change the setup now and use the new best practise so it doesn't cause a problem later on.

This is GoDaddy's statement on the change: http://help.securepaynet.net/article/6935

Simon.