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.
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:
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.
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.
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'.
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).
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.