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:
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
follow the instruction at this link:
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
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:
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
I learned how to check the URL of each of these sites through the following
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
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
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.
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.
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
-privatekeyExportable: $true This makes the cert exportable
***Note***, remove the space between “:” and the “$true” for this string. -privatekeyExportable:
(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
The record is like :
A new feature is available that enables Outlook 2007 to use DNS Service
Location (SRV) records to locate the Exchange Autodiscover service
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
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
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
Bob Lin Photography services