Home | Site Map | Cisco How To Net How To | Wireless | Search | Forums | Services | Setup Guide | Careers | About Us | Contact Us|

 

The Name of the Security Certificate Is Invalid or Does Not Match the Name of the Site

 

Case 1: When attempting to open Outlook 2007and 2010 connecting to Exchange Server 2007 or Microsoft Exchange Server 2010, you may receive the following security warning:
The name of the security certificate is invalid or does not match the name of the site.
Note This scenario applies only to Outlook clients that connect to Exchange from inside the local network. This scenario does not apply to remote Outlook clients that connect to Exchange by using Outlook Anywhere.

 


 

Check this post for more details: name of security certificate is invalid or does not match

 

Case 2: If you receive this message when using outlook anywhere, you have to generate a certificate with an external name, otherwise rpc over https won't work. but if you do this outlook 2007 got the certificate error appear when you open it.
to solve the problem we need to generate a certificate with multiple server name. you must generate the request directly from the exchange management shell.
follow the instruction at this link:
http://technet.microsoft.com/en-us/library/aa995942.aspx

Case 3: I figured out a quick work around. for the base IP address of the server I added a self signed cert that points to the internal name of the server. That of coarse broke OWA from the outside. I then bound a second IP address to the server and changed my firewall NATs to direct external traffic to the new IP address. I then added the new IP to IIS and a used the public Cert for the new address.

 

Case 4: The fix for me was 2 things. Firstly, I had a second IP address bound to my NIC and the cert was not matching up to that, so I removed the second IP on the NIC. Secondly, in IIS default website Bindings, I bound https 443 to my correct IP address (rather than All Assigned) and restarted. Thirdly, and nslookup from outside my domain had mismatching IP's for autodiscover.domain.com and email.domain.com, so I went to Netwrok Solutions and changed autodiscover.domain.com to the same IP as my email.domain.com.

 

Case 5: First off, I'm running SBS 2008 with Exchange 2007. I originally had a plain vanilla SSL cert from GoDaddy. I soon realized that there was a difference between the servername on my cert and my local server. So I revoked it and got a UCC Multiple Domain Certificate from GoDaddy, complete with a bunch of URLS:

exchange.mydomain.com
exchange.mydomain.local
autodiscover.mydomain.local
autodiscover.mydomain.com
mylocalservername.mydomain.local

This didn't solve the problem, so I got into the Exchange Command Shell and started testing URLs. Clearly, the problem had to do with URLS that started with https://sites/,.. I could see that "sites" was coming up on the Outlook certificate name mismatch error.

I discovered the world of InternalUrl and ExternalUrl on each of the sites in my server. Many of them were set to https://sites/... I also found a cool trick : right clicking on the Outlook icon on the client machine allowed me to test the autodiscover service and settings, which showed a few instances of https://sites...

I learned how to check the URL of each of these sites through the following commands:

get-AutoDiscoverVirtualDirectory | FL
Get-UMVirtualDirectory | FL
Get-OABVirtualDirectory | fl
Get-WebServicesVirtualDirectory | fl

Each of these had an internalUrl that started with https://sites/... and each had no externalUrl.

I updated each of the internal urls to look better with commands such as:
SET-OABVirtualDirectory -identity "OAB (SBS Web Applications)" -InternalUrl https://myserver.mydomain.local/...

In the end, still no luck on a whim I tried setting the ExternalUrls for each service with commands like:
SET-OABVirtualDirectory -identity "OAB (SBS Web Applications)" -ExternalUrl https://myserver.mydomain.com/...

And it worked! So, pain in the ____, and i don't know why I had to change the externalUrls, but it worked.

Case 6: Here is what I did to get mine working.

I started with VeriSign but they do not support multiple FQDN’s that I needed for my cert. Therefore, after reviewing this article and a few others, I ended up getting an Entrust Unified Communications Certificate. http://www.entrust.net/ssl-certificates/unified-communications.htm

As far as your SSL through Network Solutions, I would check with them to see if they support Exchange 2007. If they do not, get a refund. That is what I had to do with VeriSign. The Entrust cert was cheaper then VeriSign, but they took longer to generate my key.

Here is another website that helps.
http://technet.microsoft.com/en-us/library/aa998840.aspx

Here are some steps that I took to solve my problem.

1. I removed my VeriSign cert out of IIS using the wizard

2. Lunch the Exchange Management Shell

3. Depending on how many names you need, generate a cert request. Here is an example what I did.

New-ExchangeCertificate -GenerateRequest -SubjectName "c=US, o=(your domain here), cn=webmail.(your domain here).com" -IncludeAcceptedDomains -DomainName mail.(your domain here).com, mobile.(your domain here).com, Autodiscover.(your domain here).com, (Email server name 1).(your domain here).com, (Email server name 2).(your domain here).com, public.(your domain here).com -Path c:\request.req -privatekeyExportable: $true

Some notes from the above string:

cn=webmail.(your domain here).com This is the main address for my users to access webmail.

-privatekeyExportable: $true This makes the cert exportable

***Note***, remove the space between “:” and the “$true” for this string. -privatekeyExportable: $true

(The stupid thing was putting a smiley in.)

4. I just pasted this into the Exchange Management Shell and it produced a file named "request.req" on the c:\. I opened the file with notepad and copied the key into Entrust’s site when I was creating the SSL. (Just like you do with the IIS wizard.)

5. Once I got the key back from Entrust, I copied it into a txt file and renamed it to web.cer

6. I copied it over to my Exchange server and used the following command in Exchange Management Shell to import it in.

Import-ExchangeCertificate -Path c:\web.cer | Enable-ExchangeCertificate –Services IIS,POP, IMAP

(I needed POP3, IIS and IMAP4 to work as well so I added the services in)

7. Launch IIS.

8. Now, check out the cert for your server. You will notice that it is already installed and ready for use.

9. If you are using POP and/or IMAP, restart the services on the exchange server. Once the services came back up, all my errors went away.

Case 7: You may want to have enabled feature to use DNS Service
Location (SRV) records to locate the Exchange Autodiscover service. If yes,
the error will generally happen when the SRV record for the domain for
autodiscover is missing. In this issue that internal Outlook users receive
the error, you may check whether the _autodiscover SRV record exists in the
domain zone.

The record is like :

_autodiscover._tcp.domain.local

A new feature is available that enables Outlook 2007 to use DNS Service
Location (SRV) records to locate the Exchange Autodiscover service
http://support.microsoft.com/kb/940881/en-us

 

Case 8: When you access a security web site, you may receive the following security message:
The name of the security certificate is invalid or does not match the name of the site

Cause: The common name that you specified when you generated the certificate request for that Web site does not match the URL that is used to access the Web site.


Resolution:
To avoid this warning, make sure that the common name that is specified when you generate the certificate request matches the URL that will be used to access the site.

If the URL that will be used to access the site cannot be changed to match the common name on the certificate, follow these steps:
1. Create another certificate request. Make sure that the common name matches the URL that is used to access the Web site.
2. Have your certification authority generate a new certificate.
3. Use the new certificate for the Web site.

 

Case 9: If you have tried above fixes, but still have the same issue, you may want to install Exchange update or  reinstalled rollup 4 for Exchange 07.

 

 

 

Post your questions, comments, feedbacks and suggestions

Contact a consultant

Related Topics