asked on

Do you want to enforce SSL communication on the root web site?

I installed a new Exchange server certificate on my Exchange server running Windows 2008 R2 and Exchange 2010 SP1. I followed Go Daddy's instructions and everything went fine until I came to the end and a dialog box came up asking "Do you want to enforce SSL communication on the root web site? ". Unfortunately I clicked on yes. The certificate installed OK and no problems with my OWA site. However all of my network users are now having popup security alerts on their PC's about the certificate not matching (our network domain is .local and the certificate for the OWA site is .org). I tried to fix this popup alert problem by going into IIS Manager going to the default web site and unchecking require SSL in SSL settings. I restarted the IIS service and still the pop ups persist. Am I going in the wrong direction with this or do I need to reboot the server? Also are there any components besides OWA that need to remain checked?

asavener

You used to be able to get a cert with additional server principal names, but they announced they were planning to change that policy. Check with GoDaddy about whether they'll give you that kind of cert. (So you can have both .org and .local addresses supported by the cert.)

If they won't, then either your external or internal users will get the warnings. Internal users of Outlook might get some additional errors, especially if this is also an Exchange server.

Your options are either to have a dedicated web server for OWA traffic (which is what I would suggest), change internal folks to use the .org address, or live with the warnings.

alaska_guy

ASKER

The GoDaddy cert has these alternative names:

DNS Name=mail.myDomain.org
DNS Name=www.mail.myDomain.org
DNS Name=autodiscover.myDomain.local
DNS Name=autodiscover.myDomain.org
DNS Name=myDomain.local

Is this the what you were referring to as principal names. If so, how do I point internal users to the correct alternative name. It seems like the correct name should be found from the list without any outside intervention.

asavener

Yeah, I got my terminology mixed up. It's Subject Alternative Name, not server principle name.

You should be able to see from the URL or the warning message what name the internal users are using to access the server. It has to match one of the subject alternative names in the cert, and the cert chain has to be trusted.

For example, if their URL is mailhost.mydomain.local, or even mailhost, then the cert will not match. You either need a wildcard *.mydomain.local, or you need to list all of the possible names of the server as subject alternative names.

hecgomrec

I ran into this issue couple of days ago.

When you setup Exchange Server 2010 it creates a default self-signed certificate for internal use and the common name on it is usually the machinename.domainname, when you installed the new certificate you did with your external (internet facing) name which is normal but now you need to replacement he fully qualified domain name (FQDN) of the URL that is stored in the following objects:

The Service Connection Point for the Autodiscover
The InternalUrl of Exchange Web Service (EWS)
The InternalUrl of the OAB Web service

Here is what worked for me: http://support.microsoft.com/kb/940726

alaska_guy

ASKER

I think I get it now. The URL is myServerName.myDomain.local - I either need to have a wild card on the .local or have a separate alternative name for myServerName.myDomain.local - Am I on the right track?

asavener

That should work. I think GoDaddy will let you re-issue the cert without additional charge; at least they've done it for me in the past.

ASKER CERTIFIED SOLUTION

hecgomrec

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

alaska_guy

ASKER

Hecgomrec,

I am a little confused about the internal URL in the published article - Since my internal is myDomain.local should the commands be like the following:

Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUrl https://myDomain.local/autodiscover/autodiscover.xml

Edited response:
OK need to be paying closer attention - The article is about replacing myDomain.local with mail.myDomain.org. So mail.myDomain.org should be used in the commands

hecgomrec

You should replace it with your certificate name, which should be your internet facing name.

if you have a .org... you should put that.

alaska_guy

ASKER

I ran all the commands and they processed without error. I recycled the MSExchangeAutodiscoverAppPool. I restarted Exchange services. I'm still getting the security alert. Do I need to restart the server?

hecgomrec

You should restart you Default Web Site and remember: Those steps assume that a host record exists in the DNS to map the FQDN that you specify to the IP address of the CAS server.

So you should have a host record for "mail.yourdomain.com" pointing to your new exchange server IP.

alaska_guy

ASKER

I created the host record for mail.mydomain.org and pointed it to the IP address of the server.

I used the following syntax in my command

[PS] C:\Windows\system32>set-ClientAccessServer -identity "CAS01" -AutodiscoverServiceInternalUri https://mail.myDomain.org/
autodiscover/autodiscover.xml

The alert comes up as CAS01.myDomain.local - Like nothing happened

IF I use this syntax:

C:\Windows\system32>set-ClientAccessServer -identity "CAS01" -AutodiscoverServiceInternalUri https://CAS01.myDomain.org/
autodiscover/autodiscover.xml

The alert comes up as CAS01.myDomain.org -still has mismatch but at least something happened.

This is driving me nuts - I've looked at other examples of syntax and they either don't work or cause execution errors

alaska_guy

ASKER

Thanks - It is working now - My users have stopped bugging me about the security alerts - Very grateful