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

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

e.g. my.domain.com certificate also has to be my.domain.com

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 owa.company.com but rather mail.company or webmail.company, then replace that name accordingly. Autodiscover.company.com 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.

-Matt

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)

Example:

Outside we are known as:  Abcdistribution.com
But our Domain is: abcdisto.com

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

I think somehow I need to add the abcdistro.com 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:

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.

-Matt

Matt,

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, abcdistribution.com - 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 X.abcdistribution.com, 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 abcdistribution.com 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 abcdistribution.com will stop working internally, unless you add them and their proper IP address as A records to the internal zone.

-Matt

Matt,

They only zone that is listed in DNS is the abcdistro.com zone.  
The autodiscover CNAME is set to our exchange server FQDN with the .abcdistro.com 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 abcdistribution.com - that is an external hosting company.

So that might make things more complicated.  What I would need to do then is set up the abcdistro.com 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.

 
In your example, I'm assuming abcdistribution.com is your external name and abcdistro.com your internal Active Directory name.

We need to somehow get autodiscover.abcdistribution.com and mail.abcdistribution.com 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:


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

This means the new DNS zones won't block any other .abcdistribution.com 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. :)

-Matt

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 webmail.abcdistribution.com.

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.

-Matt

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 abcdistribution.com addresses.
zone.JPG
zone2.JPG

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

Select allOpen 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.

-Matt

Thank you so much -

TigerMatt

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

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?

Plancid,

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.

-Matt

Yes this is complete -