The new Windows Live Mail 2011 does not supports certain SSL connection options that were available in the previous version, causing the error A secure connection to the server could not be established. This regression problem is likely to affect many users that are migrating to Windows Live Mail 2011 and are connecting to e-mail servers that require a secure connection.
Windows Live Mail 2011 Released
Last week, I was notified by Windows Update that I had an “important” update pending. It was notifying me that there was a new version of Windows Live Essentials, called Windows Live Essentials 2011. Information on the update mentioned updating the bing toolbar, and other things, so I was leery about downloading the update because I didn’t have the bing toolbar installed. I just had Windows Live Mail and Windows Live Messenger installed.
When I went to install the update, luckily it let me choose to just upgrade the Windows Live features that I already had installed, and not install any new ones. However, it did this in an annoying window that didn’t come to the foreground, causing wasted waiting for the update that never finished until I discovered that I was being prompted to make a choice in a minimized window.
The conversation view and other new #inboxzero tools in Windows Live Mail 2011 look interesting, probably especially for someone who has a problem keeping their inbox empty. However, that’s not me. Right now, I just hope that it’s faster than previous versions of Windows Live Mail that had been a step back, speed wise, from Microsoft Outlook Express.
The SSL Connection Problem
The problem that I initially noticed though, was the error “A secure connection to the server could not be established” when attempting to establish an IMAP connection for my e-mail account. Clicking on Details showed the additional guess from microsoft of “Your IMAP command could not be sent to the server, due to non-network errors. This could, for example, indicate a lack of memory on your system.“Â The error code that is provided for troubleshooting is 800ccc0e, which has historically been the generic error for simply being unable to connect to the server.
I first checked to make sure that my e-mail server was listening on port 993 for imaps (IMAP with SSL). It was, so I did a traffic dump, and looked in the servers logs, which showed no problems on the server’s side. In fact, an error was being reported in the server’s logs, blaming the client.
Oct 23 16:16:40 bravo imapd-ssl: Unexpected SSL connection shutdown.
I found that Windows Live Mail 2011 no longer lets one connect to SSL wrapped services where the digital certificate’s common name (hostname) doesn’t match the name specified in the “Incoming mail (IMAP)” configuration option. This prevents one from being able to specify an IP address or other hostname in this field, unless it’s the exact hostname specified in the certificate.
In previous versions of Windows Live Mail, one would just be prompted with a warning that the hostname didn’t match, allowing one to continue by acknowledging. This configuration no longer appears to be available, causing a new limitation in Windows Live Mail 2011 over previous versions.
Although this was likely done to “protect” the user from some server identity related problems, unfortunately many e-mail users do not use the same hostname to connect to their e-mail server due to branded virtual hosting. The previously available warning and confirmation was likely sufficient for this protection, and removing more control from the computer user is never a good thing, especially when done unexpectedly and without explanation.
The Workaround
If you can’t figure out the workaround on your own, please feel free to follow me on twitter and then e-mail me for the password to view the rest of the article.
The obvious work around is to enter the name from the SSL certificate in the “Incoming Mail” or “Outgoing Mail” field for the servers where you’re using the “This server requires a secure connection (SSL)” checkbox.
However, most people can’t do this because the name on the certificate doesn’t resolve to the IP address of their e-mail server. This can be remedied by adding an entry in your hosts file, if you don’t have control over your DNS resolver. If you do have control over your local DNS resolver, simply add a DNS entry to resolve that name to the proper IP address.
Otherwise, edit the C:\Windows\System32\drivers\etc\hosts file in a text editor and add a line like this:
1.2.3.4 hostname
Where 1.2.3.4 is replaced by the IP address of your e-mail server and hostname is replaced by the common name in the SSL certificate. You can find this name by viewing the certificate.
Another work around would be to sign your certificate with the proper hostname. Unfortunately, this isn’t possible in many virtually hosted environments.