One of the businesses for whom I consult called me up to have me change the settings on their IIS 6.0/Exchange 2003 server so their main accountant/IT support person could get Outlook Mobile Access on his new Palm Pre. Apparently, the Pre will choke when it encounters a SSL certificate that is not linked from a recognized Certificate Authority or preloaded into the Pre. Loading the SSL Cert manually brings up another error, that the cert's address does not match the server address provided. This is the same error that the business has been receiving for their Outlook Web Access setup since they can remember. However, in IE the business can choose to accept the cert, bringing them to a login screen. They have a somewhat strange domain setup: two domains are part of their network (example.net and examplenet.com), but they only own one of them (examplenet.com), so the other (example.net) is not accessible from outside the office. The business uses mail.examplenet.com as both the office network and internet-accessible address, however the original FQDN of the server is server.example.net, which is not addressable from outside the office. DNS A or CNAME records point all connections from mail.examplenet.com, smtp.examplenet.com, and pop3.examplenet.com to server.example.net. The original SSL cert's common name was "server", not a FQDN. I thought that creating a new cert with the FQDN the office used would allow the Pre and OWA to work without error, at least for a self-signed cert. However, in the IIS management console, once I removed the old cert, created a new one (for mail.examplenet.com), signed it with the CA existing on the server, and added it to the default web server, the server was no longer addressable. Opening an IE window to the server's IP address, mail.examplenet.com, or server.example.net all would not connect. Unfortunately IE does not provide usable error codes, but I suspect it is a DNS problem in addressing the web server, as the IE error page suggestions (check address for mistakes, server could be down) are consistent with DNS misconfigurations. Replacing the original cert returned everything to the original invalid address error, but still allowed OWA (though not for the Pre). Creating and installing a cert only for "mail" provided the same error and function as the original cert. All of those certs used thus far were configured with the web server template. There was a domain controller template cert already created for "server.example.net" which, when imported, allowed error-free access to OWA when using the server.example.net address, though obviously threw an invalid cert error for the address when connecting to mail.examplenet.com. Of course, the example.net addresses cannot be used outside the office as the office does not own that domain. I would appreciate any suggestions and insight into allowing error-free (though still using SSL, and yes 128-bit encryption is enabled throughout the default web server) web access to exchange and to the Pre. Web searches for this topic merely tell me how to create a self-signed cert for the exchange/iis server, which does not appear to help by itself. The names of the domains have been changed to protect the innocent. My apologies for cross posting.

Hi, As we know that The self-signed certificate is not supported for use with OutlookAnywhere or ExchangeActiveSync. I recommend you to obtain a certificate from Windows PKI or a trusted commercial third party If you want to user self-signed certificate for OWA, then please verify the URL for you to access OWA. 1. If it is https://examplenet.com/owa, then we can follow the steps in article below to create certificate for http services(owa,pop3) 2. If it is https://mail.examplenet.com/owa, then I think wed better to obtain a SAN certificate or a wildcard certificate. You can post the domain that you want to issue certificate to here. 3. Please try to open certificate MMC and check the certificate that you have install.I recommend you to remove the certificate which is not in use. Related information to share with you: Exchange SSL Certificate and Self Signed Problems http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/88447369-5a8b-4ea6-b686-bce9a8498d0a SSL Enabling OWA 2003 using your own Certificate Authority http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html Implementing Email Security with Exchange Server 2003 http://www.msexchange.org/tutorials/Email_Security_with_Exchange_2003.html Regards, Xiu

Thank you for the reply. I found another solution that worked for the business. SSL Certificates contain two name fields, a name and a common name. These can contain two different domain names. In my case, the first name field must be the FQDN of the server in question, "server.example.net"; the second common name field must be the FQDN of the alias, "mail.examplenet.com". See the instructions for creating SSL certificates in the "Creating the Certificate Request" section to the end of this tutorial <http://www.msexchange.org/tutorials/SSL_Enabling_OWA_2003.html>. This functions almost like a SAN/UCC certificate with a limit of two domains. And it allows OWA to work without a SSL error complaining about the address mismatch so long as the root OWA cert is installed on the computers from which you want to connect. As this is an internal email server, the requirement of obtaining a purchased cert from a CA is not necessary. They are happy enough to install the root OWA cert on the small number of office computers without the additional yearly fees for a purchased cert. Once I found the dual-name solution another error popped up regarding the syncing function with the Palm Pre using Exchange ActiveSync. The symptoms follow: the device could have connection information included and connect without an error message, but would only show the outbox and would not send emails through to the exchange server. The solution was to ensure forms-based authentication was disabled and to create a secondary virtual director for the Exchange server without the required SSL restriction. See the Microsoft Knowledge Base article <http://support.microsoft.com/kb/817379>. I am unsure of the security implications of disabling the SSL requirement for the virtual directory.