Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1275
  • Last Modified:

Treo 700, bad SSL certificate for Exchange Activesync

We are trying to get the Treo 700 to work with our single Exchange 2003 SP2. We have Outlook 2003 RPC over HTTPS and OWA running on this server. The latest Treo/MS/sync software has been installed on Exchange.

Unique situation: (names substituted)

-Exchange Server host: exchmail.domain.lan (AD domain=domain.lan)

-Internet email: domain.gov

-Firewall that port forwards 80/443 to exchange:  exchmail.domain.gov   (forwards to internal exchmail.domain.lan)

-SSL self signed (openSSL) cert: exchmail

Explanation: The exchange server name differs from the internet domain used to receive email. (.lan vs. .gov). For security, SSL is forced for RPC or OWA. Internet clients must use exchmail.domain.gov to reach the server. When using OWA, the user must accept the SSL error/warning that "exchmail" is declared but connection is to "exchmail.domain.gov". This is fine for users and OWA, but Outlook 2003 can't deal with this security problem. To get around this, we put "exchmail" and the Internet IP address into the hosts file for each Outlook 2003 RPC client. Outlook then simply connects to "exchmail" over the internet which matches the name on the SSL cert.  "Tricking" the client was the only option besides installing a front end ISA server to proxy the SSL connection.  We don't use ISA server as a firewall, so this was not an option.

Problem:  We have not been able to edit the host record on a Treo 700.  The Treo Outlook reports a certificate problem.  This is likely due to either conversion of the exchmail public certificate from .crt to .cer, or the Treo can't be "tricked" using the hosts record method.    Without a ISA server to proxy SSL connections and be the front-end for RPC, can the Treo 700 work in this situation?  

If our Exchange IIS server could be configured to answer calls as exchmail.domain.lan  AND/OR  exchmail.domain.gov, a SSL self signed as exchmail.domain.gov would work.  Since OWA uses the "default" web site rather than a virtual one, the exchange server can not be both .lan and .gov........or we have not found any documentation suggesting this is possible.  

Note:  The Treo 650 is able to pull inbox, calendar, contacts from exchmail.  The Treo's use OWA as these folders are not available using POP3.  IIS is configured to only allow SSL to the OWA directories.   Treo 650 runs Palm, Treo 700 runs Windows.  

Why can we get Outlook on XP SP2 to work with RPC over HTTPS, but not with Outlook for Treo?

Any input or suggestions are greatly appreciated.
1 Solution
First problem - the forcing of SSL.
That is not compatible with OMA/EAS. You have to remove that setting on IIS.

If you cannot remove that, then you may as well send your PDAs back as they will never work.
EAS/OMA communicates with the /exchange virtual directory internally over http.
What I do in these circumstances is only allow 443 to be open on the firewall. That means that people can only connect through to the SSL port. For those users who are too lazy to enter the https in the URL for OWA, simply setup a ASP or HTTP redirect on your public web site that the users can enter which redirects them to the secure variant.

Next problem - the certificate.
Certificates work on two basis - trust and the name on the certificate and the name on the URL.
If your certificate is issued to exchmail and nothing else, then it will never work. The URL that you are entering in to the device doesn't match the certificate, so it throws and error. Nothing you can do about it.

At a minimum you will have to reissue the certificate for the FQDN that is being accessed by the PDAs in the EAS/OMA configuration.

The second problem is the trust. The certificate will need to be installed on to each device - although it looks like you have already discovered that. If you do go down the self signed root you might have better success putting the CA's root certificate on to the device - unless you are using SelfSSL which doesn't have a root.

A better solution would be to purchase a certificate. Depending on who the certificate comes from will depend on whether you need to deploy the root certificate. However a commercial root certificate is much easier to deploy than a self issued certificate.

You can get Windows Mobile to play on a single server. i have done it lots of times and have it on my home Exchange server with an iMate JasJar.


Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now