Question: We host a multi-tenant shared exchange environment and some customers are seeing a certificate warning when they open outlook as their domain name is not included in our SSL certificate as a subject alternative name.
We have a wildcard certificate for this mail server.

[![enter image description here](https://i.stack.imgur.com/Ujxkx.png)](https://i.stack.imgur.com/Ujxkx.png)

Is it possible to surpress this error or to to basically just say 'yes' permanently?

All of the users affected access outlook on a terminal server, so I'm hoping I can throw something in the registry or whatever to get rid of this or just surpress it.

Failing that, If there is a way to make outlook stop looking for autodiscover.companyname.co.uk and instead look for anything.serverdomain.com, that would also work. 

Any help appriciated.

Answer: 
It can be done - Office365 doesn't have an SSL certificate for every client. 

You need to look at using SRV and/or HTTP records for Autodiscover.

The most common reason for this error is the domain having a wildcard in it - so Autodiscover.example.com resolves somewhere. For the alternative methods of Autodiscover - such as SRV or HTTP then you need to ensure that Autodiscover does not resolve. 

If there is something on <https://example.com/Autodiscover/Autodiscover.xml> then the client needs to tell their web host to turn off Autodiscover support for their domain in the control panel. It can be done - it is just something that the host has to do. 

The behaviour of Autodiscover cannot be changed - it is hard coded on purpose so that the client tries a predictable set of URLs. You can go down the path of local XML files but that is not recommended as it is difficult to deploy and manage and are often forgotten about and therefore make troubleshooting very difficult.
Yes it can be done. However its a "configuration change" and you need another approach to "provide the service". That means you couldn´t use the hostnames from the customers, they need to use the hostname from the "master server".

In our company we have multiple different email adresses (every department has a own Domain, itservices.tld, managagementservices.tld, repairman.tld, ...). On all of them we need to have AutoDiscovery configured, however they all point to the same Exchange environment. We have so many domains that the possible alternative names in a certificate wouldn´t fit (+60 Domains) and 1-2 times per year somebody comes in with a new domain which must be added. So the construct is similar like your one.

The solution was to use a small apache server (you can also use your load balancer like we did) listen on any AutoDiscovery..tld host. If a new domain is needed we add it here. The host then performs a http redirect to AutoDiscover.itservices.tld and there an http -> https redirect is happening (do not use https on the apache server, otherwise you might get some other warnings!).

So if a user (blocks@managagementservices.tld) then configure his outlook for the first time, the outlook clients checks the DNS and finds AutoDiscover.managagementservices.tld is then http redirected to AutoDiscover.itservices.tld and this host then finally provide <https://AutoDiscover.itservices.tld/Autodiscover/Autodiscover.xml>. So the only SSL certificate we need is AutoDiscover.itservices.tld (and as well owa.itservices.tld and oaw.itservices.tld and smtp.itservices.tld). 

If a new company would then comes in you need to adjust only the http redirect and you are fine, no need to change the SSL certificate. But as a pitfall the name from the "main" environment will come up / is shown.

Its similar like the Exchange Online (part from office 365) setup. So if you need an example you could peak here I guess.