Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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:
(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

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 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?

share|improve this question

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

share|improve this answer
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
up vote 0 down vote accepted

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

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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