Setting up SSL Certificates for Exchange 2010 and my website

I am completely baffled by SSL certificates. I understand the concepts of trust and security but the actual installation and setup of certificates so that everybody is happy has always been confusing for me.

Here is my current setup:

      - Website    hosted with's web hosting service

      - Windows 2008 Server on a business network with a dynamic IP
      -        -     dynamically updated to point to my windows server

      - Microsoft Exchange Server 2010 running on the windows machine, with Outlook Web Access, IMAP, POP3 and Outlook Anywhere  (although OA is not working at the moment)
      - ""      -      setup in 1and1 to have a CNAME pointing to
      - ""           -      setup as an HTTP redirect to"

Ideally what I would like to do is purchase one or more SSL certificates from (they offer "QuickSSL" certificates signed by GeoTrust) and set it up so that:

1) Users can connect to and not get an "untrusted certificate" warning
2) Users can connect to* and use my website's online shopping cart system without getting "untrusted certificate" warnings (this website is hosted by 1and1)
3) Users can connect to outlook web access, and use "outlook anywhere" on their outlook without it failing with untrusted certificate warnings
4) Users can connect via IMAP and SMTP with SSL encryption, without it failing with untrusted certificate errors.

I really have no idea where to begin with this. I know when I buy a certificate from they'll probably hold my hand through the process of getting my actual website secured via SSL, but what about my Windows Server machine? I will need to install the certificate into IIS somehow and make sure everything lines up properly, but I don't really know what to do here.
LVL 31
Who is Participating?

SSL certificates are just about names. The point is - if you want to enable access to a certain secured site or service by it's name and prevent that visitors get warned off by invalid certificate (or even worse - fail to connect) you need to:
1) Ensure that the certificate presented contains a Common Name (CN) or Subject Alternative Name (SAN) that exactly matches the name that was used to access the site or service.
2) Ensure that the certificate was issued by a trusted certificate authority.

For Exchange services you can even manage with a single name for all services, however it requires some manual configuration regarding SRV records in DNS so if you can avoid it - do so.

GeoTrust QuickSSL supports adding up to 3 SANs to a certificate issued for some CN. Also, I've seen them advertise a free added to certificate issued for but I guess that it won't extend the number of SANs they allow per quick SSL certificate.

So the main point here would be - what names will you need? As far as I can see - this will be needed:

and possibly (depending on what you set up your OA service to use) (if someone uses that instead of when accessing your web shop)

So, we have 5 names, but can use only 4 in quick SSL.

One more thing I see as a problem is redirecting your to This is something I dont suggest because you are headed for problems if you intend to use as name for your mail server.

And since all your mail services and remote services point to a SINGLE server, there is no advantage in setting up different fqdns for them (,, since you can't stuff them into a single QuickSSL anyway.

Another thing to consider is the possibility you'll be setting up some WSS sites or possibly a RDS Gateway on your server. When that happens you'll be looking at more names to add to your certificate. But at that point QuickSSL probably won't cut it anyway.

So this is what I suggest at this point:

Get a single QuickSSL certificate for the following Common Name:

and add following 3 SANs to it:

That way you will have a certificate that will:
1) Support your public web site and web shop (,
2) Support autodiscover service for your Exchange
3) Support any public services you intend to publish from your Windows server as long as they use to be accessed.

And if you find that your DNS provider would support SRV records under free setup that you have ( you might even use some other name you WILL actually use instead of autodiscover name.

Can you pleaes check whether the OWA virtual directory is holding right certificate. If it is then choose the right certificate.  
Hi, just noticed it - sorry for me using "mycompany" and "mydomain" inconsistently but I hope you got the idea.

And to clear it up - you'll be publishing all the services from your server under (SMTP, POP, IMAP, OWA, OA...).

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

Frosty555Author Commented:

That's a huge wealth of information you've given me. Thank you!

Now as far as the actual certificates inside of exchange goes - I have no idea what I ahve in there, it would be whatever Windows Server 2008 setup automatically which is almost certainly wrong. I've been accessing everything via the name and only recently did the switch over to, so I'm sure everything is messed up now.

So when I sign up for a Geotrust SSL certificate, I tell them all three names I want (,, and then it will create a single certificate that I can import into my server? Or is it 3 separate certificates?

Or, do I "create request" on the Server, send that info off to Geotrust QuickSSL, they send me back a response and I perform a "complete request" on the Server?

Is the "SSL Certificates" section of IIS Manager the only place I need to go to configure certificates for my Windows Server machine, or are there other places I have to go tweak settings?

few pointers regarding QuickSSL first.

I purchased my GeoTrust QuickSSL certificate through and it turned out cheaper than going directly through GeoTrust. However, I have few other services active on (domain hosting, custom dns, backup mail server) so that might have influenced the pricing. I guess you'll have similar options with

Regarding the certificate creation process on dyndns in the first step I had been prompted for a CN of the certificate (Common Name - the main name for which certificate is issued). In one of the next steps I had to create the request for the common name on my IIS and copy/paste the contents of the request file (it's basically a text file usually with .req extension) into the web order for. There was a detailed instruction on dyndns how to create a certificate request for different types of web servers. In one of the final steps (maybe even as part of request approval process on GeoTrust site) I was offered to add up to 3 SANs (subject alternative names). Make sure that you set up correct e-mail addresses for certificate request approval process or you'll hit problems at some point (would be best if the e-mail referenced the - that's one of the things that confirms your ties to the domain).

A single certificate should be created as a result of that. This is important because IIS normaly won't allow you to use multiple certificates on the same server (there may be a way to override this by directly modifying the metabase but I'm not sure).

Once the certificate had been issued I imported it to IIS by finalizing the previously started certificate request process - you have assumed this correctly.

I suggest you request the certificate for as CN and, and as SANs. I don't know the insides of your hosted public site and web shop but if it can be accessed through either and it's better you include both names in the certificate to avoid problems.

The list of available certificates shows up in "SSL certificates" section. However, a specific certificate is chosen when you create a https host header (a binding) on IIS site. If you are only using IIS to access OWA and for other Exchange services then you won't have to specify host names in https bindings and you are good to go.

After you set things up it's good to do an iisreset before proceeding to Exchange configuration.

After this you should go to your Exchange and do few simple steps which are to:
- disable Outlook Anywhere on your CAS,
- reenable Outlook Anywhere on your CAS and specify the "" as a name for client access

This will be the default name distributed by autodiscover service to Outlook clients and ActiveSync devices and is covered by your cert so there should be no problems. To make sure that Exchange uses this name and not something else run the following command in your Exchange Management Shell:


The output should look like this:
Name                Server              CertPrincipalName   TTL
----                ------              -----------------   ---
EXCH                                                        1
EXPR                                                        1
WEB                                                         1

Open in new window

If it doesn't use the Set-OutlookProvider command to clear the invalid values. Syntax for that is:

Set-OutlookProvider <provider> -CertPrincipalName $null

where provider may be EXCH, EXPR or WEB.

Regarding your DNS setup, I would do following:
- set up a CNAME to point to
- remove the mapping you created for

The final note is that isn't a must in your cert but sure minimizes problems. This is why:
- if your e-mail is the autodiscovery first tries to locate the autodiscovery service at
- if that fails an attempt is made to locate the autodiscovery at - which in your case points to a wrong IP
- if that fails an attempt is made to locate the autodiscovery by address pointed to by SRV record in your DNS which might look something like this in your case: 60 IN SRV 10 0 443
which tells that autodiscover service requests should be redirected to (here's some basic info on SRV records). However, this option requires that your DNS provider supports SRV records (probably does) but also that your autodiscover partners (Outlook,...) know how to utilize them.

There are some other steps Outlook can perform in Exchange autodiscovery if that fails, but this is something I never rely on due to required certificate names.

Finally, remember that any secured service you'll be publishing (pop...) will have to refer to for server name and may require some additional setup depending on your requirements.

And if you ever plan to put things like RDS Gateway on the same machine it will have to use the same name because this service is tied in with IIS (meaning that when you change the cert in either console it automatically changes the cert for the other service too - can cause some headaches until you realize that :)).

Well, that's about it - good luck with your setup!

Frosty555Author Commented:
tstritof: thank you very much for your help, you've made this a LOT clearer to me.

A little update - it turns out that does NOT give you the certificate that you purchase, and they do not support using the certificate anywhere other than their own servers. After a run around with their support, none of which are as knowledgable on the subject as you, they eventually just stopped returning my emails.

Pretty ridiculous when you think it's a standard Geotrust certificate that I can get anywhere, I expect to have access to the services I've purchased.

On your suggestion, I think I'm going to demand my money back from them and purchase one from DynDNS - since you've had success with that in the past.
No problem. I can recommend DynDNS, they are one of the best on-line services I've ever used - easy to work with, 0 outages in 4 years and not bugging the customer with spam.

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.

All Courses

From novice to tech pro — start learning today.