Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Ok, so I have two subdomains going to my Exchange box at work (Exchange 2007 on Server 2008). The internal subdomain is and the outside domain is Our AD domain is the same name as our website domain. Our DNS server internally points to the Exchange box, and so does is not pointed to anything on the outside DNS.

So, in order to enable people to get to their email from outside and make it easier to deal with phones and such connecting in, I bought a GoDaddy SSL certificate the other day, and installed it. Unfortunately, the GoDaddy certificate points to, and everyone's Outlook is directed to Therefore, people keep getting a "Certificate is valid, but the domain it is assigned to does not match the domain it is on" kind of message. I don't remember the exact wording.

Anyways, my question is this: How do I set up one certificate (the one distributed by the trusted CA from inside my company) to be used for MAPI, and the other to be used for IIS? Or, even better, if the machine is accessed as, use the GoDaddy, if it's, use the internal CA cert.

share|improve this question
up vote 2 down vote accepted

Since you've said in a comment you don't want to use a wildcard certificate, you need 2 SSL certificates, and 2 IP addresses on your Exchange server.

SSL certificates are bound 1 per IP+Port combination in IIS, so by adding a second IP to the Exchange server you can assign back your original internally generated SSL certificate that was being used before you bought the new one, or another purchased SSL certificate referring to, and assign to the new IP address, again in IIS.

You then point your external port forwarding to the new second IP address with's SSL certificate bound to it.

It's a bit fiddly, but it should work ok for you.

share|improve this answer
Ok, maybe I wasn't entirely clear about this. I have two certificates. One issued by my domain controller/internal certificate authority. Another issued by GoDaddy. is on our outside IP address, and has the GoDaddy certificate on it. has our internal IP address on it (192.168.x.x) and has the cert issued by our internal CA. All I want to do is set this up so that MAPI goes out using, and IIS uses – phuzion Dec 24 '09 at 5:18
Have you got 2 internal IP addresses on the Exchange server setup? You need to do that, and assign 1 SSL certificate to each IP. 192.168.x.y with the external SSL cert 192.168.x.z with the internal CA cert Make sure DNS resolves correctly internally for both IP addresses, and point your port forwarding from the external firewall to the IP address with the external SSL cert. That should work – Ewan Leith Dec 24 '09 at 9:33
Thanks, I'll try this. The bounty is yours. – phuzion Dec 28 '09 at 15:38

The better way, and best practice way to do this is with a UC certificate, also known as a SAN (Subject Alternative Names) cert. HERE is some great info on how/what a SAN is and how it works.

But basically, the cert with have several names in it, most likely: netbios server name, local server FQDN, your webmail url, and an autodiscover url

As an additional note, I have a similar setup on one of my servers. It's running Sharepoint and Exchange 2007. I have a SAN cert with the following:

servername, servername.domain.local,,,

This allows my Outlook clients to connect to Exchange without certificate warnings, and also my Sharepoint and OWA sites from the inside and outside without any warnings as well. This also makes my clients able to connect using Outlook Anywhere with the Autodiscover.

Probably not the answer you want to hear, but tossing the 2 separate certs in favor of a SAN is going to save you a TON of headache when it comes to IIS, the need for multiple IP addresses, host headers, etc, that you would need to fool around with to get it working the way you want.

share|improve this answer
There's a good blog entry on the Exchange Team Blog about requesting and configuring SAN\UC Certs - – Helvick Dec 22 '09 at 14:20
We've made great use of SAN's here in our Exchange environment. – sysadmin1138 Dec 24 '09 at 18:19
See my thread here on a good SAN cert provider. (Its a subsidy of GoDaddy, IIRC)… – DanBig Dec 24 '09 at 18:25
This is a better answer. Consider re-assigning the accepted answer. – Jason R. Coombs Apr 19 '10 at 3:10

wildcards used on POP3 and IMAP as part of an Exchange implementation can be tricky, although it can be done. If you look around this site, you will notice overwhelmingly people go with the UC certificates when it comes to exchange.

see Wildcard SSL Certificates with Exchange 2010?

If you do decide to go with wildcards, you may find SSLTools Manager for Windows useful in troubleshooting errors including the dreaded 'name mismatch error'.

share|improve this answer

The easiest way to acomplish this is to use a wildcard SSL certificates although these are quite expensive. This will allow the certificate to be used for * and you will not have to worry about certificate settings on your Exchange infrastructure.

Another way is to publish your OWA via ISA Server. This will allow you to have a different certificate for the external facing OWA. The communication between ISA and your backend OWA server will however be over http (unencrypted).

share|improve this answer
I'm not looking to use a wildcard certificate. I have two valid certificates, I'm looking to make Exchange push one for IIS, and one for MAPI. And I don't have ISA, so no go on that. – phuzion Dec 22 '09 at 13:32

Wildcard certificates are free, once you have passed the $40 Class 2 validation at

I am using their certs on all my servers including Exchange 2010.

share|improve this answer
I get errors trying to assign the wildcard certs to the POP3 and IMAP services (WARNING: This certificate with thumbprint 7FEF753A521B73E81F93A56F464D8700C5A567DE and subject '*' cannot used for POP SSL/TLS connections because the subject is not a Fully Qualified Domain Name (FQDN). Use command Set-POPSettings to set X509CertificateName to the FQDN of the service.) – Jason R. Coombs Apr 19 '10 at 3:09

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.