Outlook complains about mismatched names on ssl cert

We are going to be renewing our ssl on our exchange 2010. I know that will will no longer be able to use the .local name on the cert. I also know that since this will be missing on the cert, most of our internal outlook users will start getting errors about the name mismatch. One of my coworkers mentioned that he found an article to suppress this error so the users do not receive this annoying pop up. Unfortunately he hasn't had a chance to find the article that he used. Does anyone know what he might be referring to? Thank you.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Simon Butler (Sembee)ConsultantCommented:
Don't suppress the error - instead correct your Exchange configuration.
You need a split DNS system so that the external name resolves internally.


You can implement that at any point, if you have an SSL certificate with the correct external name on it already, then you can make the change before you renew your SSL certificate, that way all clients should get the new configuration with Autodiscover.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
I've never seen a way to specifically suppress the warning, other than importing the cert (potentially with GPO).  That said I've always found MS documentation to be unclear, and when I rolled out 2010 I must have read dozens of third party articles.  I'll try to summarize it,  MS documentation is written with the assumption that you have a split DNS environment.  Also note you need a SAN certificate so you can have alternate names on it.  Don't buy into anything about a wildcard cert!

At a minimum you would need autodiscover.contoso.com and mail.contoso.com on your cert.   At this point you would create internal DNS record for mail.contoso.com pointing at either a CAS server or your load balancer.  Do not create autodiscover record on your internal DNS.  Change the InternalURL properties on OAB & WebServices virtual directories to mail.contoso.com.  Don't change the OWA, ActiveSync and ECP InternalURL properties yet that's something to consider separately.  You must also change the AutoDiscoverServiceInternalUri property on every CAS server in the site to mail.contoso.com.  Import your SAN certificate and enable it for IIS services.  Normally you can only have one cert enabled for all IIS based services, but at this point the names on the cert will match the InternalURL props and the Autodiscover..URI.  So it plays out like:

1) Outlook starts and queries AD for the SCP of autodiscover services.  https://mail.contoso.com is returned because it was set as the AutodiscoverInternalServicesUri.
2) Mail.contoso.com resolves to your CAS server (or LB).  There is no inconsistency on the cert so no warnings.
3) CAS server returns autodiscovered information like OAB URL and EWS URL which are both based on the aforementioned respective InternalURL properties, hence the cert names are still consistent and no warnings.

If you have to expose your Exchange services externally you only need to enter the external DNS records and update the ExternalURL properties on OAB, WebServices, OWA, ActiveSync & ECP virtual directories.  Notice I'm not excluding ActiveSync and OWA for the ExternalURL properties.  This is withstanding firewall configs and such that are too diverse to discuss here.

There are 2 other things worth mentioning:
1) SSL offloading done by FW, TMG server or possibly the load balancer could be used, this would require you to disable the SSL requirement on all the virtual directories.
2) You could disable SSL altogether.  Again you would need to remove the requirement from each virtual directory in IIS, you may also need to flip a reg key to enable http based CAS-CAS proxy.  Then you'd change the URL props and the Autodiscover..Uri to http://mail.contoso.com.

The hybrid approach is external URLs are https while internal are http.  The FW or LB is terminating the SSL connection, otherwise known as SSL offloading.

This is the most complicated piece of Exchange 2010, so I hope I did enough to explain it, please post back if anything is unclear.

If you are going to expose Exchange to the internet you need to create
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.