Link to home
Start Free TrialLog in
Avatar of Travis Hahn
Travis HahnFlag for United States of America

asked on

Security Certificate - The name on the security certificate does not match the name of the site

We are having an issue after we upgraded to Exchange 2010 - all of our Outlook 2007 and 2010 users get 2 security alerts when they start Outlook.  The Error says:

Security Alert

The name on the security certificate is invalid or does not match the name of the site.

Once the user clicks yes twice everything works (Execpt for Microsoft Exchange offline address book - which i believe to be related)

Our internal domain name is different from our outside domain name - which is where the problem is I believe.

I believe that powershell will be involved - but I am no Exchange Guru and I am not quite comfortable with poweshell enough to go adding some code to my certificate.  Can anyone help?

Avatar of Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Andrew Hancock (VMware vExpert PRO / EE Fellow/British Beekeeper)
Flag of United Kingdom of Great Britain and Northern Ireland image

you need to purchase a certificate which has the same as the fqdn of the external site name.

e.g. certificate also has to be

Do you have a trusted third-party SSL certificate installed in your Exchange Client Access environment? If so, which one?

You ideally need a Subject Alternate Name (SAN) certificate (also known as a Unified Communications Certificate or UCC) installed which lists a number of names which Outlook, OWA and mobile devices will use to communicate securely with your Exchange organisation:


The internal server names are included because Outlook will use these to communicate with Exchange when a user is connecting internally. It isn't strictly required (you can get away with just the public names), but you have to implement split DNS and make a lot of changes in Powershell, so I'd only advise you omit the first two if you are comfortable with making those changes.

The latter two refer to external access to OWA and Exchange ActiveSync when outside the company network. If you don't use but rather or, then replace that name accordingly. is used when a user attempts to automatically configure Outlook when not on the network -- Outlook goes looking for their configuration settings by prepending autodiscover. to the part after the @ in their email address. If you have multiple email domains receiving email through this server, you will need multiple autodiscover entries - one for each domain.

There is a great wizard in the Exchange Management Console on the Server Configuration page which walks you through the basics of generating your certificate request. Once you've generated it, you'll need to submit it to a trusted third-party supplier and have them approve it. GoDaddy are my usual recommendation, and for under $100/year to bypass the security warnings and improve your user experience, it is worth its weight in gold.

Avatar of Travis Hahn


I wasnt here when they set up the Exchange server - but I do believe that there is a trusted SSL certificate inplace from GODADDY.

Matt I think you touched on what I possible need.  If I look at the details of the certificate in Subject Alternative Name - it shows 5 DNS names with all but one being out outside domain name.  There is no reference to our internal domain name on the certificate (which is what the users login to)


Outside we are known as:
But our Domain is:

There is no other email servers in the network...

I think somehow I need to add the to the certificate or to exchange...
That sounds like where your issue lies.

In your screenshot you posted above, you blanked out the domain name. Can you give me a rough idea which name is referred to in that SSL warning? It should be a name that isn't listed in the SAN names on the SSL certificate, because that's the reason the box is appearing.

You have two options:

Add the internal network names, and servername, to the SAN field on your certificate.
You'll need to get back to GoDaddy or the original supplier to do that. However, since your internal name is a .com, this raises a potential problem if you don't actually own / have control over the domain name. When the names are added to the certificate, a Certification Authority contacts the listed owner to confirm their identity and that they made the request. If someone else owns that domain, you won't be able to get the certificate generated. This is one of the reasons I tend to use .local or .internal for Active Directory domains, or if I do use a public .com or, I make sure the company owns the domain.
Failing the above, we can adjust the URLs on the Exchange Virtual Directories and the Autodiscover SCP so that all communication, internal and external, uses the external names listed on the certificate. This will also require split DNS for your external domain name -- I don't know if you have this configured but it is a required step in the process. This step is much harder than the first one I mentioned, so I'd only recommend it if the domain is beyond your control.
I can walk you through any and all of these steps as necessary once you let me know exactly what position you are in with regards to the internal domain.


You are correct the SSL warning domain is NOT listed in the SAN of the certificate.  We do not own the internal domain name on the outside - I didn’t setup the infrastructure - so I am trying to fix the problems from the previous IT guy.

So I think the second scenario is what will need to happen - I really appreciate your help on this,

Okay. Option 2 it is then.

First things first, can you check for me if your external domain - that is, - is listed as a zone in your internal DNS infrastructure? In your typical Active Directory environment you should find DNS on the DCs.

If it is listed, we need to know whether the following records are listed inside that public zone, and if not, add them:
obviously evaluating to the full FQDN of, where X is the record out of the list above. Each record needs to resolve in some way to the Exchange Server, whether that is by A record to the Exchange Server's internal IP or by CNAME to its internal name. I prefer the CNAME record because it means you're not hardcoding IP addresses in places you're likely to forget.

This is split DNS at its core -- we're resolving the same names differently depending on whether you resolve them internally (where they go to an internal name) or externally (where they go to the public IP of your Exchange Client Access environment).

If that zone isn't set up, then you don't have split DNS. If you are comfortable creating and populating it with records, by all means go ahead and do so. If you aren't, let me know and I can talk you through it. Don't forget that creating it means all subdomains of will stop working internally, unless you add them and their proper IP address as A records to the internal zone.


They only zone that is listed in DNS is the zone.  
The autodiscover CNAME is set to our exchange server FQDN with the and set to static

There is not Specific MAIL (MX) record in this zone at all

This also might be good to note - we dont host our website of - that is an external hosting company.

So that might make things more complicated.  What I would need to do then is set up the to resolve to our internal servers.  Could you give me one example so that I can see?
Check on your send connectors to see if you have the external dns option set. If so try de-selecting it and see if that clears the issue.

Below is an example of this configuration on a huge deployment I administer.

 User generated image
In your example, I'm assuming is your external name and your internal Active Directory name.

We need to somehow get and to resolve internally to the internal name/IP of your Exchange Server, while having it still resolve externally to the public name.

If blocking out the whole zone is an issue, we can create multiple zones with the names which match the records we need. Here's how I'd suggest you proceed:

In DNS, create a new primary, AD-integrated zone. The name of the zone should be
Inside your new zone, right click, New CNAME record, leave the record name blank and then have it map to the internal FQDN of Exchange, i.e.
Once created you should get a (same as parent folder) record inside that zone.

Repeat this process, this time for (or whatever you use to access OWA externally).

This means the new DNS zones won't block any other sites, such as your externally hosted website, from being resolved internally.

By the way, I completely understand this was never your mess in the first place, and we're here to try to fix it. I might just mention useful or important details at times to ensure the answers here are complete for the knowledgebase and future searchers of EE with the same issue. :)

Okay I got the autodiscover one created - but I have another issue.  When I try to go to our OWA internally is does not resolve.  I do believe it is

How can I find out for sure what address our OWA is using - so that I can set up the zone.
Nevermind - I found were it was.  So since the External and the Inernal URL's are different - I could create a DNS record that forwads internal to the EXTERNAL URL.  Correct?  So that no matter where I hit OWA from it resolves to the same location....

Well, once this is done, you won't need to have an internal URL for OWA, because the external one will work whether you are inside or not. This is the beauty of split DNS -- it means users don't have to learn two URLs.

Have you managed to create those DNS zones yet?

That's the hardest part. Once that's done, we just need to update some Exchange Virtual Directory configs so Outlook refers to the correct URLs.

I will be checking out soon, but will be back tomorrow.

Okay - I think I have this done. I have attached a snip-its from DNS Manager - let me know if they look correct.  They all have the INTERNAL domain name for FQDN not the addresses.
Avatar of tigermatt
Flag of United Kingdom of Great Britain and Northern Ireland image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Matt - If these changes are made and they are not correct what kind of issues may happen?  They will not be able to connect to outlook?  

How hard will it be to set the info back to what it was IF this dosent work?  

I am a little hesitent about doing this...

They might get a bunch of SSL warnings until the proper settings are put in place, that's all.

These are the same settings I make on most of my Exchange deployments, so as long as everything is fine split DNS wise, nothing should be a problem.

You can note down the current settings by replacing "Set" with "Get" in each of my above commands, wiping out the parameters and putting | fl InternalURL,ExternalURL on the end. E.g., for ECPVirtualDirectory:

Get-ECPVirtualDirectory | fl InternalURL,ExternalURL

Open in new window

Repeat for all the other commands I listed above and note down the two URLs if set. (The last command is different, you'll need to run Get-ClientAccessServer | fl AutodiscoverServiceInternalUri).

Should there be a major issue, you can then set the URLs back using the list of Set- cmdlets from my previous post -- replacing the -InternalURL and -ExternalURL with the values you noted down.

I can't see there being any significant issues, though.

Thank you so much -

I am finally doing this - entering in one of the commands has brought me to this:

cmdlet Set-OwaVirtualDirectory at command pipeline position 1
Supply values for the following parameters:

I  have tried FQDN/OWA in quotes and it dosent work.  What am I doing wrong?
Was this ever solved? We are having the same issue and I'm not finding what to enter for the Identity. Can anyone help?

It looks like I somehow missed the Author's reply more than a year ago (March 2011!). I do not know how, but that is unfortunate. My apologies, jtobak.

You need to enter the Identity as "SERVER NAME\Owa (Default Web Site)". This is the identity for the virtual directories. This needs modifying appropriately for the other ones.

For each Set-***VirtualDirectory command, you can run Get-***VirtualDirectory. This will give you the identities of the virtual directory/ies, which you can then plug in to the Identity prompt in the Set- command.

Yes this is complete -