I have a problem with my newly setup Exchange environment for our hosted customers.

First off, when configuring the outlook client, it gives a certificate warning although the certificate has been bought and setup.

I am using a setup like this:
autodiscover.CUSTOMERDOMAIN.TLD CNAME autodiscover.exchange.COMPANYDOMAIN.TLD
(Companydomain is our company that hosts the exchange servers, customerdomain being the customers domain)

Shouldn't that work? I know that Microsoft does something like that for Office365, but I really don't think they buy a certificate for every customer..

So I guess some redirection should be setup somehow - any guidance?

Next thing: When we accept that error, and move on to actually starting Outlook, it states that the certificate is not valid for the RPC proxy server exchange.COMPANYDOMAIN.TLD - this domain is not right, as that domain is not included in the certificate. I would instead like this domain to be mail.exchange.COMPANYDOMAIN.TLD

I tried to run this script setting both internal and external URL's to be the same, with no luck.

Any guidance on this one?

I am running Exchange 2010 SP2, with CAS, HT and MBX split up on 3 different servers.

Update: I have now fixed the issue with the RPC proxy server.

The commands used was: To see what it is currently set to:

get-outlookanywhere |fl externalhostname

To set it to something else:

set-outlookanywhere -identity "exchcas01\rpc (Default Web Site)" -externalhostname "NEWHOSTNAME"

However, I am still having issues with the first problem.

Update 2:

I have gotten further with the first problem. I have setup a small nginx server, that basically only redirects all requests sent to the server to https://autodiscover.exchange.COMPANYDOMAIN.TLD/Autodiscover/autodiscover.xml and this works.. Not so well.. as Outlook tries to create a unsecure connection. How can I redirect from the requested URL, to the SSL URL, without Outlook making a mess?


A certificate will only be valid for the exact host name it was created for. That's the "CN" (Common Name) part of the "Subject" field in the certificate.

The typical way to deal with what you're doing is to buy a certificate with another field called "Subject Alternate Names" where you can list other hosts name that should be considered valid by the client. These certificates typically are a bit more expensive (although not always).

  • I know that. It just can't be right that it won't be possible without buying more certificates? – Frederik Nielsen Sep 12 '12 at 8:47
  • Why do you say that ? A certificates used in SSL, by default, will only allow you to authenticate again a single host name. If you have more than one host name, as in your case, you need to use a certificates that allows for all these names or buy a different cert for each one of these names and bind them to a different IP (In your context, unless you're willing to switch to 2012, at least, there is no other way). – Stephane Sep 12 '12 at 12:44
  • I am not asking for help about the certificates - but about how to avoid using them for others than our own domain. I don't want to buy certificates for all our customers. I actually found this technet article, which describes pretty much what I want to do, so I am gonna test that. – Frederik Nielsen Sep 12 '12 at 13:12

This Technet article was exactly what I wanted - to setup some simple redirection that Oulook understands.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.