Link to home
Create AccountLog in
Avatar of Infinity Solutions
Infinity SolutionsFlag for United States of America

asked on

How can we enable SSL for mobile users for Exchange 2010

First I would like to say that our domain is a .local and not a FQDN in active directory.   Ex.  john.local
Exchange 2010 sp1
Originally setup with a self signed cert
OWA is using http
mobile clients are not using ssl (but we would like to turn this on)

Things we have tried:

Creating a signed Certificate (for this we did have change the entries to be .com to be able to get a certificate)

1- Backup the existing directories from the exchange management shell

Get-WebServicesVirtualDirectory | Select InternalUrl,BasicAuthenticationExternalUrl,Identity | Format-List

Get-OabVirtualDirectory | Select InternalURL,ExternalURL,Identity | FL

Get-ActiveSyncVirtualDirectory | Select InternalUrl,ExternalUrl,Identity | fl

2- Set the directories to use .com names

Set-WebServicesVirtualDirectory -Identity "EXCH-1\EWS (Default Web Site)" -InternalURL -BasicAuthentication:$true

Set-OabVirtualDirectory -Identity "EXCH-1\OAB (Default Web Site)" -InternalUrl

set-ActiveSyncVirtualDirectory -Identity "EXCH-1\Microsoft-Server-ActiveSync (Default Web Site)" -InternalUrl ""

3- Enable outlook anywhere and configure it

Use the EMC to enable Outlook Anywhere
You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Outlook Anywhere configuration settings" entry in the Client Access Permissions topic.
a.       In the console tree, navigate to Server Configuration > Client Access.
b.      In the action pane, click Enable Outlook Anywhere.
c.      In the Enable Outlook Anywhere wizard, type the external host name or URL for your organization in the box under External host name.
This is the URL, for example, that users will use to connect to the Exchange server by using Outlook Anywhere.
d.      Select an available external authentication method. You can select Basic authentication or NTLM authentication.
Basic authentication sends the user name and password in clear text. It also requires that users enter domain, user name, and password every time that they connect to the Exchange server. When you use NTLM authentication, the user's credentials are never sent over the network. Instead, the client computer and the server exchange hashed values of the user's credentials. NTLM can also use the current Windows operating system logon information.
Even though it's more secure, NTLM may not work with firewalls that examine and modify traffic. You can use an advanced firewall server such as Microsoft Internet Security and Acceleration (ISA) Server 2006 together with NTLM authentication for Outlook Anywhere.
Negotiate Ex authentication is an authentication type that's reserved for future Microsoft use and should not be used. Use of this setting will cause authentication to fail.
e.      If you're using an SSL accelerator and you want to use SSL offloading, select the check box next to Allow secure channel (SSL) offloading.
Select this check box if you'll be using a separate server to handle Secure Sockets Layer (SSL) encryption and decryption. When you use SSL offloading, the firewall in front of the Client Access server ends the SSL session and then establishes a new non-SSL session to the Exchange server.
Don't use this option unless you're sure that you have an SSL accelerator that can handle SSL offloading. If you don't have an SSL accelerator that can handle SSL offloading, and you select this option, Outlook Anywhere won't function correctly.
f.      Click Enable to apply these settings and enable Outlook Anywhere.
g.       Click Finish to close the Enable Outlook Anywhere wizard.

4- Change the default cert to the new SSL cert

5- Assign services to the new cert

6- Verify that the default website is using the new SSL cert and that there is an https binding with the new cert

This is a production environment also
Avatar of Jeff Glover
Jeff Glover
Flag of United States of America image

After all that, I assume you are looking for an answer for the original question of Using SSL for Mobile Users? Like iPhone and Android or Windows Phone? The first and most important thing is the signed cert? did you get it from an External provider like Digicert, GoDaddy, Thawte, etc....? If not, and it is an internally generated cert, you will need to get a public Cert for it. it needs to have the URL used for ActiveSync and Autodiscover on it. Normally, you set OWA and ActiveSync to use the same URL so you would have the names for your owa service and activesync as SAN names. You can also use a wildcard. COmpare costs.
  Without a Public Cert, you cannot use SSL with mobile clients easily. ( I suppose there may be a way to manually import the cert into each phone but I do not know it offhand).
Avatar of Infinity Solutions


Yes we would like to use ssl for mobile clients still.  We are using android and iphones.  The cert we bought is a public cert is a public certificate.  We are actually able to connect using ssl if we are on the same network as the server using wifi.  There is currently DNS setup for our owa and it is working i might add.  It is only using http though.  


Active Sync

(This is not the actual domain name but I wanted to show you both OWA and Active Sync are using the same names)

I am currently onsite if you have any suggestions
Avatar of Jeff Glover
Jeff Glover
Flag of United States of America image

Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account is also in the cert.  When I run the microsoft connectivity analyzer I get the results below

      The Microsoft Connectivity Analyzer is testing Exchange ActiveSync.
       The Exchange ActiveSync test failed.
      Additional Details
      Test Steps
      Attempting to resolve the host name in DNS.
       The host name resolved successfully.
      Additional Details
      Testing TCP port 443 on host to ensure it's listening and open.
       The port was opened successfully.
      Additional Details
      Testing the SSL certificate to make sure it's valid.
       The SSL certificate failed one or more certificate validation checks.
      Additional Details
      Test Steps
      The Microsoft Connectivity Analyzer is attempting to obtain the SSL certificate from remote server on port 443.
       The Microsoft Connectivity Analyzer wasn't able to obtain the remote SSL certificate.
      Additional Details
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
Elapsed Time: 5584 ms.

We have port 80 and 443 forwarded to our exchange server currently.
Who is the certificate from?
Link to home
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
I did not import it previously but I did just import it and it did not improve the connectivity analyzer
And your GoDaddy certificate is assigned to the IIS services in Exchange? (Had to ask)
Yes while testing.  We are having to turn off the services once we are done testing ssl connectivity due to a popup of certificates for our local users.  

I do want to mention the domain we use for our local pc's is different.


Our local domain is infinity.local
Our public FQDN is
The different domain name is of no consequence. As long as your have set the Autodiscover URI to the External FQDN  like, it should work. When you connect to webmail via SSL, and it gives you a certificate warning, can you click on the certificate and view it. Does it show your GoDaddy certificate and does it show the full certificate chain?
Autodiscover has never worked externally for this exchange setup.   We currently manually config the phones
Ouch. So what URL do you manually configure the phones to? Is it on the Certificate? is the domain and it is included in the certificate
I am not sure what else can be checked. If, when you access, you get a certificate error (when you enable SSL), The only thing I can think of left to check is whether or not the certificate was installed correctly.
ok so i found final part that fixed the issue was that our barracuda actually uses port 443 for the vpn and that cannot be changed.  So we are using port 444 on the phones with a rule on our firewall forwarding anything not destine for the vpn to the server and it is now working
needed to do use a different port due to our barracuda firewall causing the issue