Saturday, February 21, 2009

Certificate errors in Outlook when connected to Exchange Server

I had recently set up an Exchange Server 2007 server for my company's email. The server needed to handle both internal and Internet mail. Once we figured out how to configure the server to send and receive Internet email (see my post on configuring Exchange 2007 for Internet email: http://thingsthatshouldbeeasy.blogspot.com/2007/02/configuring-exchange-2007-for-internet.html), we set about configuring the server to allow company users outside of the company's network to connect to the server with Outlook.

We added an SSL certificate to the Exchange server with the server's Internet FQDN (mail.comapny.com) and configured Outlook Anywhere (the new name for RPC over HTTP from Exchange 2003). We then configured the Microsoft Exchange Proxy Settings in Outlook. At first things seemed OK. External users were indeed able to connect to the Exchange server without having to VPN into the company network.

Then we noticed that users on the internal company network were starting to receive SSL certificate errors when Outlook started up. To make a long story short, it turned out to be an issue with the way we created the SSL certificate for the Exchange server and the ways in which Outlook connects to Exchange.

When Outlook and Exchange are on remote networks and the Exchange Proxy Settings are configured in Outlook, Outlook will try to connect to the Exchange server using the external FQDN of the Exchange server over HTTP or HTTP protocols. In our case, this was [mail.company.com]. This is why the external users did not receive SSL errors: the external users were accessing the server using the [mail.company.com] address, and that is the address that was in the subject name field of the Exchange server's SSL certificate.

However, when Outlook and Exchange are on the same network, Outlook will connect to the Exchange server using remote procedure call (RPC) using the server's internal name. In our case this was [exchange.company.local]. That's why the internal users were getting the certificate error: the Exchange server's internal name, [exchange.company.local], did not match the subject name of the SSL certificate, [mail.company.com].

In order to make things work, we needed to generate a certificate that would contain both names of the Exchange server. This is often referred to as a subject alternate name (SAN) certificate. Unfortunately, there is no user interface for creating such a certificate. I found this great post by Ronen Gabbay on adding a certificate to the Exchange server with subject alternate names (SAN):

Fair warning: you will need to use the Exchange Server 2007 Power Shell command line in order to complete the steps in the article. Also, make sure to read the comments as they point a couple of typos in the command lines listed in the post.

Once I replaced the old SSL certificate with a new one with [mail.company.com] as the subject name, and [exchange.company.local] and [exchange] as subject alternate names, both internal and external users were able to access the mail server with no errors.

27 comments:

I need to post my thanks for a simple explanation that has resolved my problem. After trawling the internet and speaking with support at my SSL supplier you have provided a spot on answer with easy to follow instructions.

I do this work for my alumni association gratis and have gotten a certificate that exhibits the symptons you mention. i.e users can access outlook web access but not internal users. Our name is www.school.org and the internal name is school.school.local. As I am doing this for free and am already out a couple hundred bucksfor the useless certificate, I am reluctant to order a new certificate and was wondering if you could help me with the proper context to use on the webconsole..

If you look at the original post and comments, replace "ServerName.internal.com" with "school.school.local", replace "autodiscover.demo.com" with "autodiscover.school.org", replace "ServerName" with "school", and replace "mail.demo.com" with "mail.school.org". This assumes that "school" is the NetBIOS server name for you email server, "mail.school.org" is the external SMTP, OWA, and Outlook Anywhere address, and "school.school.local" is the internal FQDN. Of course this help is provided "as is" and standard disclaimer of non-responsibility, non-accountability, and non-liability applies :)

I'm taking over as the IT person for a small private school and new to SBS 2003, which is what we use. I'm also new to SSL certificates. I've already gotten some questions about why the dreaded certificate error appears when users attempt to use Outlook Web Access with certain browsers. My question is, could I have the reverse problem that you mention in this article, that maybe we do have a certificate, but it only points to school.local and I might need to add a SAN for the external address? Where in the SBS2003 administration would I go to check this? Our main website is hosted elsewhere on www.school.org and that web company has already secured a certificate for the main domain, but everything else (mail, etc is on our SBS2003 server). Is it possible we have no certificate at all for the mail server (either internal or external) or is it not possible to run without one? If internal mail is working properly with no certificate errors does that just mean we have the certificate but it's just in need of the SAN for the external domain? Also, I believe right now OWA is set up as https://www.school.org/exchange - could I use that address for a certificate or must I set up a TLD, e.g. mail.school.org?

I'd be very grateful for any info you can help me with. I know it doesn't sound like it from this message, but I have a wide array of IT experience, which is why I was hired for this position, but I have major holes in my Network Administrator knowledge because I have only been exposed to certain pieces of it in the past.

You definitely could have the reverse problem as you put it, though in fact it is really the same problem: users accessing your Exchange server from two different Urls but the SSL certificate does not have both Urls.

However, since you mention that the users only get the error with certain browsers (implying that things work correctly with other browsers), it may not be quite the same error. It may be that you are using a certificate that generated by an internal certification authority that is not trusted by users' machines. If that's the case you will need to provide your users will instructions on obtaining your certification authority's public key certificate and adding it to the list of trusted authorities on their computers and browsers.

We used a certificate from an internal domain certification authority. You do not need to pay for a certificate from an outside certification authority like Verisign, as long as you have you Active Directory domain policy configured properly so that the domain computers trust your internal CA.

I am in a process of upgrading/migrating my Exchange server environment to Exchange 2010 server, in that regards I have installed Exchange 2010 and doing OK with downloading mails in domain environment (when logged on domain and outlook is configured )and in OWA. but some how not able to get mails working for Outlook Anywhere....here is the error which I am getting when trying to download mails with IMAP/POP configuration

This is the only method I know of to fix the issue. You might be able to somehow configure Exchange to use the external Url for all clients, but doing that is outside of my skills set. The easier thing to do is see if you can get a new certificate issued with both the internal and external names. Good luck.

You know I really should know this as I have been doing this for a long time, but I still cannot wrap my brain around naming certificates. PLEASE HELP! I have a large project coming up and the main issues are certificate errors. It's always the names for me. I can get certificates imported into the trusted store, but the names never match and that is where I draw a blank...WHAT NAMES do I put on my certificates???

Let say my exchange 2010 server is setup with a name NEW-SERVER.

My internal URL for mail is..

https://new-server.mydomainname.local/owa

My external URL for mail is.

https://webmail.mydomainname.com/owa

WHAT DO I GET FOR MY CERT NAMES? This is what I never learned. I understand certificates and why they do what they do, but I do not know how to properlly name them when requesting them. HELP!

I am about to rebuild this server as it is hosed. If I rebuild from scratch and use SBS 2011 from the get go I will still be using the name NEW-SERVER...will I need to do the same thing? a SAN cert with both names?

You have to re-import the cert, because you will need the updated cert file with the new expiration date. I suppose it is possible to auto-deploy updated certs using system management software, but that is outside of my area of expertise.

Why don't you just create an internal DNZ zone on your AD DNS server to match (if it doesn't already) your external domain name, then create an A record that points to the internal IP address of the Exchange server? That way, when staff connect externally, it uses public DNS to resolve mail.company.com and if they're connected to the local network, it will query the internal AD DNS servers which has a zone for company.com and an A record for mail which points to the local IP. Easy as.

That isn't always possible. Here are just a few that come to mind... Some organizations have already have different internal and external DNS namespace and it would take too much work to unify them. Creating a certificate with a SAN is much easier. In other cases an organization may have multiple public DNS name spaces but has only one internal. Also you may need to have the DNS (and resulting Urls) be different between internal and external zones if you are using many types of load balancing or access policy network appliances / software.

After a week and a half of searching and trying probably a hundred different solution, I have found the one that worked. This was awesome and I truly appreciate the help. If it weren't for this site and the one sourced I would have been lost and would have had to hired an outside company to come in and fix this issue. Truly, thanks.

Subscribe via email

Followers

About Me

Eugene Rosenfeld is the CTO of Black Blade Associates, a products and services company focused on making SharePoint useful to DoD, life sciences, and financial services organizations. Eugene holds a strong belief that all systems should have the innate ability to intelligently communicate with one another. Most recently he has been heavily involved with distributed systems architecture, Services Oriented Architected (SOA), peer-to-peer systems, and cloud computing.

Eugene has been recognized for his community involvement by Microsoft through their prestigious MVP program. Eugene speaks regularly at various SharePoint events and user groups, and also maintains his blog, "Things that Should be Easy". Check it out for tips that may make your current project a little easier.

A Black Blade Associates blog. Struggling with SharePoint? We can help.

Every so often (too often in the IT industry) I encounter things that should have been very easy to do but turned out to be far too complicated. Hopefully posting them here will allow others to avoid the same issues. My favorite topics include SharePoint, .Net development, and software architecture, especially distributed systems.