Exchange Certificates Don't Match Up

Solution 1:

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.

Solution 2:

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.

Solution 3:

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