Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Ok, so I have two subdomains going to my Exchange box at work (Exchange 2007 on Server 2008). The internal subdomain is exchange.company.com and the outside domain is webmail.company.com. Our AD domain is the same name as our website domain. Our DNS server internally points exchange.company.com to the Exchange box, and so does webmail.company.com. Exchange.company.com 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 webmail.company.com, and everyone's Outlook is directed to exchange.company.com. 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 webmail.company.com, use the GoDaddy, if it's exchange.company.com, use the internal CA cert.

share|improve this question
add comment

5 Answers

up vote 2 down vote accepted
+100

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 exchange.company.com, and assign webmail.company.com to the new IP address, again in IIS.

You then point your external port forwarding to the new second IP address with webmail.company.com'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. webmail.company.com is on our outside IP address, and has the GoDaddy certificate on it. exchange.company.com 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 exchange.company.com, and IIS uses webmail.company.com. –  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. webmail.company.com 192.168.x.y with the external SSL cert exchange.company.com 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
add comment

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, autodiscover.domain.com, go.domain.com, internal.domain.com

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 - msexchangeteam.com/archive/2007/02/19/435472.aspx –  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) serverfault.com/questions/80507/… –  DanBig Dec 24 '09 at 18:25
3  
This is a better answer. Consider re-assigning the accepted answer. –  Jason R. Coombs Apr 19 '10 at 3:10
add comment

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
add comment

Wildcard certificates are free, once you have passed the $40 Class 2 validation at http://www.startssl.com/

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 '*.jaraco.com' 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
add comment

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 *.company.com 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
add comment

Your Answer

 
discard

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.