Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 6731
  • Last Modified:

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?
0
alaska_guy
Asked:
alaska_guy
  • 6
  • 4
  • 3
1 Solution
 
asavenerCommented:
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.
0
 
alaska_guyAuthor Commented:
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.
0
 
asavenerCommented:
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.
0
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

 
hecgomrecCommented:
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
0
 
alaska_guyAuthor Commented:
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?
0
 
asavenerCommented:
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.
0
 
hecgomrecCommented:
Yes, you can re-key the certificate to include more than one name.... just keep in mind this certificate will be exposed on the outside and everyone will see the name of your internal server plus the domain name.

It will be more correct to follow the instructions on the link I provided you, anyways like that your site will be accessible with the same name inside or outside your organization if you have the proper DNS record that points to your server in your organization.

Just my 1 cent of advise.
0
 
alaska_guyAuthor Commented:
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
0
 
hecgomrecCommented:
You should replace it with your certificate name, which should be your internet facing name.

if you have a .org... you should put that.
0
 
alaska_guyAuthor Commented:
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?
0
 
hecgomrecCommented:
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.
0
 
alaska_guyAuthor Commented:
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
0
 
alaska_guyAuthor Commented:
Thanks - It is working now - My users have stopped bugging me about the security alerts - Very grateful
0

Featured Post

The Lifecycle Approach to Managing Security Policy

Managing application connectivity and security policies can be achieved more effectively when following a framework that automates repeatable processes and ensures that the right activities are performed in the right order.

  • 6
  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now