"Name on the Security Certificate is Invalid or Does not Match..." using Outlok 2007 w/ Exchange 2007
-
Wednesday, January 31, 2007 7:17 PM
Good afternoon!
We just completed our Exchange 2007 implementation (migration from Exchange 2003... a fun romp of 24 straight hours for the final push) and noticed an error that only occurs on Outlook 2007 clients connecting to the Exchange 2007 server: "Name on the Security Certificate is Invalid or Does Not Match the Name on the Certificate".
Now, I've done my reading into this and have determined that due to how Outlook 2007 clients managed their OAB, it is essentially through a web virtual directory now, no longer through Public Folders and this is essentially the base of our issue. See, our mail server has an internal FQDN of mail.ourdomain-domain.com whereas it has an external FQDN (which is what the SSL Cert is tied to) of owa.ourdomain.com.
So, essentially what I'm seeing is our internal Outlook 2007 clients (limited to I.S. employees only right now, thankfully) are seeing this SSL error because Outlook 2007 is trying to pick up the OAB using the internal FQDN instead of the external FQDN (which would work as well, due to some internal DNS trickery we have configured).
My question is (finally), is there a way to circumvent this internally so we never see this SSL error prompt or a way to force Outlook 2007 to use the external FQDN? I have made sure all the settings in Exchange Management Console for OAB and the like have both the internal and external FQDN set to owa.ourdomain.com (the valid SSL name), but it does not appear to have made a difference. Granted, I have not rebooted... but I do not think that is necessary in this instance.
Any suggestions would be appreciated. Thanks!!
All Replies
-
Tuesday, February 06, 2007 12:22 AMWe have a similar problem in that our SSL certificate shows secure.domainname.com rather than the hostname of the Exhchange server. As we have SSL enabled applications OTHER THAN EXHCNAGE, we do not want Exhcnage 07 to redirect to the machine name but instead to a relative path UNDER the URL specified by the client request:
https://secure.domainname.com/exchange is how a user would get to OWA, and we want any redirection to go to https://secure.domainname.com/owa and so on. So far we can not see where in IIS we would make that change.
Also, messages work to Palm 700p devices but we get a failure on other content, like appointments and contacts. The error is related to the SSL certificate not matching the Exhcange server. I will post the error in a while.
Does anyone know how to tell IIS/OWA to redirect to a relative path? -
Tuesday, February 06, 2007 3:19 AMFollowing up, the Palm 700p error message when trying to use ActiveSync is:
There was a problem syncing events. Can't connect to server. Please check your network or server settings and try again: AirSAMStateMachine.c 530 3
And we have a valid SSL Cert from a root CA. The error is ONLY on non-email items, so we assume when the app goes to a specific application on the web server, it is redirected using the hostname of the server, not a relative path. -
Thursday, March 01, 2007 3:36 PM
Craig,
We are having the exact same issue. Were you ever able to resolve this?
-
Sunday, March 04, 2007 8:29 PMWe're seeing htis issue as well.. Server name is mail02b.{domainname.net} but externally is accessed at exchange.{domainname.com} so we got the SSL cert for exchange.{domainname.com} and set IIS up to redirect the website users appropriately. That all works fine, but Outlook 2007 is apparently stuck with accessing the server at mail02b.{domainname.net} and as such pops a cert not valid error when starting up.
-
Thursday, March 08, 2007 1:52 PMHave you found a solution to this issue yet? I'm having the same problem. If there is no fix for this, Microsoft needs to create one as more and more companies switch to 2007.
-
Friday, March 16, 2007 4:26 PMwe're also experiencing this...hope there is a fix soon
-
Wednesday, March 21, 2007 3:03 AM
As all of you, I have the same issue, and I'm sure that will be many more. Luckily, I only have a handful of users on Outlook 2007, and they have just been dealing with it for about a month now. The best answer I have gotten from anyone is to get a wildcard cert of *.domainname.com. I have not tried this yet, so it's still theory to me whether Exchange 2007 will let it fly or not. On top of that...wildcard certs cost a good bit more than the typical certificate. :(
I agree that a better solution should come from Microsoft about how to deal with their new changes.
jb
-
Wednesday, March 21, 2007 2:51 PM
Hello Guys,
after few days of research, I found the matter of this problem, and I wanted to post this, because I hope you won't waste the time as myself.
the problem is much simple as you think, because exchange autogenerate the certificate even if a CA in not present in the AD.
then when you would like to use 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
Emanuele
ciao
-
Wednesday, March 21, 2007 3:32 PM
Manu_it wrote: Hello Guys,
after few days of research, I found the matter of this problem, and I wanted to post this, because I hope you won't waste the time as myself.
the problem is much simple as you think, because exchange autogenerate the certificate even if a CA in not present in the AD.
then when you would like to use 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
Emanuele
ciao
Hi,
The solution of Emanuele is only useable for a new certificate request. I have an existing certificate and dont want to generate (and pay) a new one.
is there another solution? I also found this article but did not test it: http://www.pro-exchange.be/modules.php?name=News&file=print&sid=345
Janpaul
-
Thursday, March 22, 2007 2:11 AMI too have spent much time trying to find a reasonable solution to this problem of outlook 2007 client producing an error "The name on the security certificate is invalid or does not match the name of the site". Of all my researching though, I have not found anything that has been put out by Microsoft to directly address this. This is going to continue to become a significant issue as more and more business' migrate to the new technologies of the 2007 product line. I hope we can get a resolution from Microsoft soon. --BN
-
Tuesday, April 03, 2007 4:14 PMHello, I went to Vista here a week ago. I am running 64-bit Ultimate and I am having constant Certificate invalid messages in IE7 as well. I just installed my copy of Office 2007 Enterprise edition and whenever I open up Outlook I get the same "security certificate that can't be verified" message, and I am using Comcast for email. Now on IE7, when I look at the certificate issuing authority it says the name of the website (take USAA for example, it says it was issued 12/06 and is valid until 12/09, and says it is from www.usaa.com) when they are actually (according to the site and other computers I checked) by a certificate authority. I was running XP Pro 64 bit with IE7 and didn't' encounter these problems, but Vista is starting to torque me off now! At least when I went to FireFox it didnt' have the certificate errors! Oh, BTW, I have disabled/uninstalled Defender, the UAC and all that other garbage that is in Vista, if that helps! Hell, I even tried dropping the internet and intranet security settings to their lowest and still get the certificate issues! Might roll on back to XP next weekend!!
-
Tuesday, April 03, 2007 7:05 PM
Someone call feel free to correct me if I'm off, but...
The rollback to XP will not remove the certificate issue. However, roll back to Office 2003, and I feel comfortable saying your problem will probably go away. At least in my enviroment...I have XP and Vista boxes, and the only ones with certificate problems are the ones with Office 2007 installed.
-
Monday, April 09, 2007 1:19 PMHaving the same issues on our network. I'm hoping there's a work-around for this soon.
-
Monday, April 09, 2007 4:25 PM
There is a work around. I have deployed OWA with ISA 2006. I had already a 3rd party certificate. The certificate was issued on the following address webmail.domain.com. I could not use this certificate on the new exchange 2007 server. To get rid of the certificate error on outlook users internally i have created a certifcate request on exchange 2007 server with the powershell commandlet
New-ExchangeCertificate -generaterequest -subjectname "C=NL,DC=Organisationname,O=Org description,CN=domain.com" -domainname webmail.domain.com,autodiscover.domain.com, cas1.domain.local, cas1 -path c:\certrequest_cas01.txt
This is a certificate request with multiple host and domain names. There is external domian name and also the local domain name on the certificate.
After creating the request, I opened from IE my DC certificate services http://192.168.0.1/certsrv
select the Request a certificate and then advanced certificate request.</LOCID< Font> then Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
Paste the csr that is creaated with the exchange cmdlet in to the field and select the Web server certificate template. Than
submit the request. The certificate will be created download it and place it some where.
Import the created certificate in to exhcange server with the cmdlet and not with de certificate mmc snapin. After importing the certificate change the certificate on the IIS to the new created certificate. The clients must have the certificate autohoruty root cert in the client pc's. That is achived when you already did deploy the certificate services on your network. The certificate error must disappeer and OWA will also work just fine. This is only to fix internally the cert problems. If you want to deploy autodiscover.domain.com on external side of your network than you must buy a 3rd party UC with multiple hostnames.
I have put the following host and domainnames in the cert request.
- domain.com (external domain)
- webmail.domain.com
- autodiscover.domain.com
- cas1 (exchange server name)
- cas.domain.local
- domain.local (internal domain)
I hope that will solve your problem.
-
Tuesday, April 10, 2007 11:18 AMI've thought about creating a certificate with multiple names (or a wildcard-type) but from what I have read, devices running Windows Mobile 5 are not able to recognize wildcard certificates. This would affect our deployment as we plan on running ActiveSync on some of our handhelds.
-
Thursday, April 12, 2007 7:13 AM
Hi,
Does anyone have a solution to this yet? The one a couple of posts from Oguz up is fine assuming you are using homemade certificates, but if you have a certificate from a CA which doesn't match the name of the Exchange Server (which must apply to a heap of people) I don't beleive it works (well it doesn't for me anyway). There is no way the name on the cert can ever match the name of the Exchange Server unless your internal and external domains are the same and you publish the name of your Exchange Server to the outside world (unless I'm mistaken). I have followed the articles from MS which mention changing the OAB, UM and WebServices virtual directories to have an external URL but this makes no difference either. Plus another article I found regarding using the enable-Exchangecertificate cmdlet to enable the cert on services such as SMTP which aren't by default apparently.
From what I can see the problem is with the Outlook profile. When you put in the server name, even if you put in the name of the server as it is published to the outside world (rpc.company.com), it still resolves that to the internal Exchange Server name (server.domain.local) and this is where the issue seems to arise when Outlook 2007 starts as it tries to make a connection but fails due to mismatched names on the certificate and the Exchange Server. This happens even if you set the RPC over HTTPS settings to turn off using HTTP on a "fast network".
Hope someone can help here.
Cheers,
Rich
-
Wednesday, April 18, 2007 7:41 PM
Hello,
Any update on this? I just installed my CA yesterday just to find out that my webmail works fine but Outlook 2007 gives me the invalid cert because of the different name. I am also having this problem with Outlook 2003 POP users “The server you are connected to is using a security certificate that could not be verified.”
Thanks for any help you can provide.
Mike -
Wednesday, April 18, 2007 8:27 PMWelcome to the insanity.
-
Wednesday, April 18, 2007 8:58 PMThanks!
-
Monday, April 23, 2007 5:34 PM
I too am running into this issue on an SBS 2003 R2 server using Exchange 2003 with SP2, and Windows Server 2003 Service Pack 2. Outlook 2003 clients on either XP Pro with SP2 can connect over the Internet no problemo using the same self-generated certificate, as can Outlook 2003 clients on Vista, but ANY Outlook 2007 clients, regardless of whether 2007 is installed on XP or Vista, get the certificate error noted in this thread, again with the same certificate.
Is there any indication a patch will be forth-coming?
-
Monday, April 23, 2007 6:44 PM
Well I figured out what my problem is. Read this article from the MS Exchange team.
http://msexchangeteam.com/archive/2007/02/19/435472.aspx
-
Thursday, April 26, 2007 7:07 PM
@R6 Mike
I've read through but I'm still a little confused. From my understanding I would have to create a "special" multi-purpose certificate (not in IIS), register it with some small third-party company I've never used, and then apply this new "special" certificate to the server (again not through IIS). What about if we've already purchased an SSL cerificate from a large company such as Network Solutions? Does that mean the certificate is useless?
If the answer is yes, then I can't say I'm very impressed with this product thus far. Apart from crashing installs, new non-standard certificates and other issues it's been a complete nightmare. That will teach us for going to a new version before the masses. I really hope Microsoft comes up with a patch for this.
(Oh and I wasn't directing my frustration at you, just the product in general. Thanks for letting me vent!)
-
Thursday, April 26, 2007 9:32 PMHere 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.
I hope this helps. -
Friday, April 27, 2007 5:01 PMThanks Mike,
I will try to refund our certificate and start fresh. That tutorial is very helpful as well! Thanks for the info. I actually got in touch with Microsoft Premiere Support and discussed why directionally they chose to go with these new certificates (note that wildcard certs will not work), and the rep wasn't actually sure either. He seemed to think it was because it would be more convenient to include multiple names on a single cert. At this point though, very few providers will actually provide this multi-name cert which is fairly confusing and frustrating.
I also asked if they would release a patch or reg key change to suppress the actual Outlook error messages people are getting. The long and short of it is that if they did, they would deem it an unsupported install. I'm guessing that once more people start rolling this out and hitting the same errors they may change their tunes though.
Regardless, it looks like I'll be heading back to the drawing board with our Exchange deployment. Thanks again for your help! -
Friday, April 27, 2007 5:59 PMNo worries. Glad I could help!
-
Wednesday, May 02, 2007 3:19 AMThere are some solutions to the multiple-name-on-certificate problem on this Exchange blog post http://msexchangeteam.com/archive/2007/04/30/438249.aspx. These guys offer a cert which is a bit cheaper than the other multiple-name ones so far: http://www.comodo.com/msexchange/.
The problem is that you need the cas server's name in the cetificate. If not, Outlook Anywhere won't work properly. No CA will give you a cert for the server name in some of the above example posts, cas.domain.local. Many people however will be using such a name. Don't know the solution to this problem... -
Wednesday, May 09, 2007 4:30 PM
My problem is the same as you other guys have. I get the error message : "The name on the security certificate is invalid or does not match the name of the site" this occurs when users running Office 2007 starts Outlook to connect to the new wonderful Exchange 2007 server. But the name of the server is correct except that is doesn’t have the domain name of active directory. I wonder now if I should take the chance to make a new server certificate on the exchange server and call it the server name + the domain name. ?
Like this is is today the exchange server name is : somethingex64. And the new should be like this somethingex64.domain.local. As I now remember our firewall ISA server 2006 was very precise that the name of the certificate should be only the name of the server. Hmm. This for the relaying of the HTTPS traffic from the other certificate I bought to let the users get an easy address to remember. The other certificate that I am now struggeling with is the intarnal one which forwards the https traffic from the firewall to the exchange server.! I am so bored of this certificate issues now that I really wonder to switch to http instead. The whole process has been ok except that it has been many hours and long evenings managing the correct configuration. It is now really frustrating that the communication between the clients and the server INTERNALLY has this very complex way to communicate.
Any Ideas anyone. ?
(From an exchange 2007 setting that is wonderful, except the certificate error warning message) -
Monday, September 24, 2007 7:47 PMThe last post on here was some time ago. Has anyone found a solution other than getting a new certificate issued with multiple names?
Thanks,
Rick -
Monday, October 01, 2007 10:15 PM
I've been curious about getting a solid simple solution to this issue. The only way I've been able to get the certificate error to be removed is the make the DNS address static, then switch the order of the DNS.
Most networks are setup for DHCP. If you switch the network order in Start>Network and Internet Connections>Network Connections>Right Click Network connections> Properities>Internet Protocol>Use Following DNS Server. Automatically is usually the option of choice. Switch that to use the following, determine IP addresses of network, switch the order that is currently setup. That removes the certificate error. I don't know if that's the best answer, but it seems to work.
-
Wednesday, October 03, 2007 12:03 AMHas anyone been able to find a fix to this?
I have having this problem and didn't know if it was because i was using a GoDaddy Cert.
If i need to get a real cert, like one from Network Solutions or EasyDNS i can do that.
But didn't know if it would fix the problem or not.
Thanks! -
Thursday, October 04, 2007 4:14 PM
Has anyone tried repointing the Autodiscovery to the existing SSL using:
Set-ClientAccessServer -Identity CASserver1 -AutoDiscoverServiceInternalUri https://yourinternaladdress.xxx
If so does it prevent 2003 outlook clients from accessing Exchange 2007 server as I have a hybrid enviroment.
Thanks
-
Tuesday, October 16, 2007 4:52 AM
dude, you are the win. That worked perfectly, setting both CAS servers url to my 3rd party cert url worked flawless. Thansk
. -
Wednesday, October 24, 2007 8:31 PMSo I ran that also, and hooray. The cert error is gone, but as a result of that I cannot see any free/busy schedule when scheduling meetings. Does anyone else know what else needs to be ran?
-
Wednesday, October 24, 2007 8:45 PMDisregard the last post. I figured it out, and again, Whoohoo it works.
Set-ClientAccessServer -Identity CASservername -AutodiscoverServiceInternalUri https://mail.yourmailnamehere.com/autodiscover/autodiscover.xml
Thanks for all the information and help from everyone! -
Thursday, November 01, 2007 7:02 PM
-
Saturday, November 10, 2007 2:11 AMI have been plagued with the same errors "The server you are connecting to is using a certificate that could not be verified." I am brand new to Exchange and have recently set up Exchange 2007 on a standalone server. My clients are using Outlook XP, so I have to use POP for them to receive mail, because I don't want the travelling laptop users to have to use VPN whenever they want to connect to the exchange server. Here is my questions: Why do I need to set the autodiscovery to the external URL when I'm not even using autodiscovery. This is only for Outlook 2007 users right? All I recall using is OWA and POP accounts to fetch mail the old way. I have certificates with Startcom and of course gave them my external FQDN for the certificate. OWA works great after installing the certificate, but of course the Outlook client itself gets that annoying popup. I know it was probably explained above, but I think I need another explanation due to by noobness. Thanks much!
-
Monday, November 12, 2007 6:20 PM
FWIW i reinstalled rollup 4 for Exchange 07 and my problems went away.
T
-
Monday, November 12, 2007 10:37 PMOK Great! I will try that and let you know if it works.
-
Monday, November 12, 2007 11:04 PMHmm, didn't seem to solve the problem for me.
-
Friday, February 15, 2008 7:45 PMAlso, just another tid bit of info. Wildcard certs are not supported in Windows Mobile 5 so if you have any of those devices, don't do it.
-
Friday, February 15, 2008 7:46 PMAlso be aware that Windows Mobile version 5 does not support wildcard certs so if you have any mobile users using that platform don't do it.
-
Tuesday, March 11, 2008 4:35 PMI've seen a way to supress this error in outlook using the resource kit and a GPO, but i can't find it again. Will post when i do.
-
Wednesday, June 18, 2008 1:37 PM
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.
so far everything looks good.
Now if anyone can tell me how to masquerade my SMTP mail to my external FQDN, ill be very happy
-
Friday, June 20, 2008 10:22 PM
jml44 wrote: In addition to that last command, check out this article:
http://support.microsoft.com/kb/940726
I know this is an old thread, but here is what we were facing:
Internal Exchange 2007 (Server 2008): server9.internal.domain.name
External Exchange 2007: webmail.domain.com
We purchased a SSL Cert through GoDaddy for webmail.domain.com, but did not include the additional host names in the CSR.
Some users are running Outlook 2003, some Outlook 2007. The Outlook 2007 users were getting the error in the subject heading of this thread. I followed the instructions from the KB article above, (http://support.microsoft.com/kb/940726) and that resolved the problem perfectly! -
Friday, July 25, 2008 1:39 PM
Oquz,
This worked as explained - thank you for posting
-
Tuesday, February 17, 2009 3:03 PMFor the record, if one ever delete the self signed SSL cert create by Exchange 2007, you only need to run this command in the Exchange powershell:
New-ExchangeCertificate -PrivateKeyExportable $True -Services “IMAP, POP, IIS, SMTP” -SubjectName “cn=[Your server name]and the cert is back
-
Tuesday, June 16, 2009 8:23 PMHi,
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.
good luck -
Monday, August 10, 2009 10:39 PM
Hi All,
1) I am using Windows SBS Server 2008 with Exchange 2007 installed on it. With all the Certicate configured internally. We haven’t purchased the Certificate from any outside authority yet.
2) Also, user were getting Error message "The name on the security certificate is invalid or does not match the name of the site" in outlook, to resolve this issue I followed the steps mention on "http://support.microsoft.com/kb/940726" & “http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/697f79e2-ca8f-4a2e-bae5-55d3fa7f703f/?prof=required” however I was able run only first command as I was unable to find "EWS (Default Web Site)", "oab (Default Web Site)", "unifiedmessaging (Default Web Site)".
3) After reaserching, I run following commands to get the status, location of WebServicesVirtualDirectory, OABVirtualDirectory & UMVirtualDirectory
[PS] C:\Windows\System32>Get-WebServicesVirtualDirectory | fl
Name : EWS (SBS Web Applications)
Server : PASVR01
InternalUrl : https://sites/EWS/Exchange.asmx
ExternalUrl :
[PS] C:\Windows\System32>Get-OABVirtualDirectory | fl
Name : OAB (SBS Web Applications)
Server : PASVR01
InternalUrl : https://sites/OAB
ExternalUrl :
[PS] C:\Windows\System32>Get-UMVirtualDirectory | fl
Name : UnifiedMessaging (SBS Web Applications)
Server : PASVR01
InternalUrl : https://sites/UnifiedMessaging/Service.asmx
ExternalUrl :
4) Then after getting the correct locations of all the directory I run the following commands to change the internal url on existing Certs
Set-ClientAccessServer -Identity PASVR01 -AutodiscoverServiceInternalUri https://pasvr01/owa/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "PASVR01\EWS (SBS Web Applications)" -InternalUrl https://pasvr01/owa/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "PASVR01\OAB (SBS Web Applications)" -InternalUrl https://pasvr01/owa/oab
Set-UMVirtualDirectory -Identity "PASVR01\UnifiedMessaging (SBS Web Applications)" -InternalUrl https://pasvr01/owa/unifiedmessaging/service.asmx
5) However, this does'nt resolved our issue so run the following commands to change the external url on existing Certs
Set-WebServicesVirtualDirectory -Identity "PASVR01\EWS (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "PASVR01\OAB (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/oab
Set-UMVirtualDirectory -Identity "PASVR01\UnifiedMessaging (SBS Web Applications)" -ExternalUrl https://exchange.domain.com/owa/unifiedmessaging/service.asmx
6) I also tried running "New-ExchangeCertificate -PrivateKeyExportable $True -Services “IMAP, POP, IIS, SMTP” -SubjectName “cn=PASVR01" as I have deleted one of the certicate on this server in past.
7) Following was the status of internal and external URL.
[PS] C:\Windows\System32>Get-WebServicesVirtualDirectory | fl
Name : EWS (SBS Web Applications)
Server : PASVR01
InternalUrl : https://pasvr01/owa/ews/exchange.asmx
ExternalUrl : https://exchange. exchange.domain.com /owa/ews/exchange.asmx
[PS] C:\Windows\System32>Get-OABVirtualDirectory | fl
Name : OAB (SBS Web Applications)
Server : PASVR01
InternalUrl : https://pasvr01/owa/oab
ExternalUrl : https://exchange. exchange.domain.com/owa/oab
[PS] C:\Windows\System32>Get-UMVirtualDirectory | fl
Name : UnifiedMessaging (SBS Web Applications)
Server : PASVR01
InternalUrl : https://pasvr01/owa/unifiedmessaging/service.asmx
ExternalUrl : https://exchange. exchange.domain.com/owa/unifiedmessaging/service.asmx
10) Still we are facing this issue of "The name on the security certificate is invalid or does not match the name of the site" in outlook.
PLEASE HELP ME TO RESOLVE THIS ISSUE.
Thanks in Advance,
Asif
- Edited by A-S-I-F Monday, August 10, 2009 10:42 PM security
-
Monday, December 14, 2009 5:10 AMFor what it's worth (a few months after the post), I just had the same problem and solved it after HOURS of research and testing.
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. -
Monday, December 28, 2009 7:38 PM
IM haveing ssl Certificate proplems in exchange with outlook 2007 however i need to see what current domain names its popping up with and i have run this command in the exchange managment shell and i get the following.
[PS] C:\Windows\System32>get-AutoDiscoverVirtualDirectory | FL
Get-AutodiscoverVirtualDirectory : Unable to create Internet Information Servic
es (IIS) directory entry. Error message is: Access is denied.
. HResult = -2147024891.
At line:1 char:33
+ get-AutoDiscoverVirtualDirectory <<<< | FL
What am i doing wrong????????
Thanks IN advance -
Thursday, December 31, 2009 7:27 AMUnbelievably, this worked for me...
Go into IIS and into your Application Pools for your exchange server. Right click 'MSExchangeAutodiscoverAppPool' and click 'Recycle'.
That's all I had to do... -
Friday, January 22, 2010 8:37 AMTry this:
In Outlook, go to Accounts Settings => Ms Exchange server=>Change=>more settings =>Connection =>Exchange Proxy Settings.
Uncheck "Only connect to proxy servers that have this principal name in their certificate:"
Restart Outlook -
Thursday, April 01, 2010 8:11 PM
You need to right-click the "Exchange Management Shell" and select "Run as Administrator" or login as the domain/local administrator.
This should allow you to run this command.
-
Monday, April 05, 2010 12:36 AM
I had this problem after installing Exchange 2007 SP2.. a bit late with applying SP2 I know.
It took me a good 8 hours of frustration with some breaks in between before I worked out 3 things:
- I didn't read KB940726 http://support.microsoft.com/kb/940726 carefully as it wasn't making sense to me to include the external certificate url for the internal cas and at first I was only using the internal names.
- The commands from that KB in Powershell worked, however the problem didn't go away until I logged in with the Exchange admin rights and performed those commands... I'm still not sure if this is needed, but it worked on these servers I had.
- Added entries for the external cert url in the hosts files of both cas servers - this might be an issue for some that need to get to it from the internal LAN, in my case this is not needed.
The topology I had this problem with was the following:
> Exchange 2007 running on WS2008 with roles of CAS, Mailbox, hub transport server
> Exchange 2007 running on WS2008 with roles of CAS server that has the external certificate installed and is configured for OWA from the internet
> Client configurations: Citrix servers running Outlook 2007 SP2
Prior to applying SP2 we had never seen or had Outlook certificate errors and I built both servers from scratch in late 2008... so this was weird to me how I didn't need to run or configure the servers to know about the external cert back then... maybe it's something new with SP2 for 2010?
-
Friday, April 23, 2010 5:14 PM
Yes YES, perfect resolution.
Set-ClientAccessServer -Identity CASservername -AutodiscoverServiceInternalUri https://mail.yourmailnamehere.com/autodiscover/autodiscover.xml
Our situation: Exchange 2007, internal Office 2007, external IE 8. Applied a new GoDaddy SSL cert to our exchange2007 which serves out our OWA web mail too to enable SSL for the ouside OWA, worked great, but that broke the internal users, who then started to get the error of not a trusted site blah blah above...only Outlook 2007 users...2003 worked fine.
After running the above command, with my info in it, poof, instant fix! No reboot needed, no services bounced, nothing, the user just needed to close and reopen outlook, whoot!
-BagpipperMan
-
Friday, October 01, 2010 4:15 PM
Well I figured out what my problem is. Read this article from the MS Exchange team.
http://msexchangeteam.com/archive/2007/02/19/435472.aspx
This worked. You need to make sure you know what domain names you have in your UCC certificate.
My problem was I didn't own the internet domain name that was the same name as our internal domain.
Exchange uses https://netbiosname.domainname.com/virtualdir as the link to the exchange services for outlook 07 and outlook 10. And since I wasn't able to have server.domainname.com in the certificate I had to change it to the name I did have in there. Which was just the server name. Here are my below commands I had to run. As soon as I ran them, closed and opened outlook, there was no more "certificate error" prompts.
Old setting
Set-ClientAccessServer -Identity SERVER -AutodiscoverServiceInternalUri https://SERVER.infinityinvestmentsinc.com/Autodiscover/Autodiscover.xml
NEW
Set-ClientAccessServer -Identity SERVER -AutodiscoverServiceInternalUri https://SERVER/Autodiscover/Autodiscover.xml
OLD
Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)" -InternalUrl https://SERVER.infinityinvestmentsinc.com/EWS/Exchange.asmX
NEW
Set-WebServicesVirtualDirectory -Identity "SERVER\EWS (Default Web Site)" -InternalUrl https://SERVER/EWS/Exchange.asmx
NOW
Set-OABVirtualDirectory -Identity "SERVER\oab (Default Web Site)" -InternalUrl http://SERVER.infinityinvestmentsinc.com/OAB
NEW
Set-OABVirtualDirectory -Identity "SERVER\oab (Default Web Site)" -InternalUrl https://SERVER/OAB
I hope this helps someone out. It took me a while to figure out but it is all good now.
w0rd -
Tuesday, October 26, 2010 7:47 PMWinner!!!
-
Thursday, November 04, 2010 7:06 PM
This all works well if you have the server names on the cert.
My scenario is I have a wildcard cert (*.domain.com) for all internet facing devices and services and like you, I have an internal domain that I do not own (internaldomain.com). I couldn't just use the server (netBios) name like you did because my cert only accepts URLs with the wildcard nomenclature anyname.externaldomain.com.
Therefore all I did was take what you did and add my external domain suffix to the end of the server name.
e.g. Set-ClientAccessServer -Identity SERVER -AutodiscoverServiceInternalUri https://SERVER.externaldomain.com/Autodiscover/Autodiscover.xml
One important (and obvious to most in the IT arena) tidbit is that you must have dns configured correctly internally so that it points to the internal server IP from the internal network (e.g. exchange-CAS.externaldomain.com A-record points to 192.168.XXX.XXX). I have access to all services so this wasn't a problem for me, but for some you may have to talk to your network folks to have them add this to your DNS servers.
Anyway, thank you so much for the cmdlets. All is well now.
-
Saturday, December 18, 2010 2:41 PM
hey guys,
herewith the solution:
in most of cases the problem is with the DNS, so on the client computers (those which are running outlook express 2007) you have to nodify the host file in the windows, usually located in:
C:\Windows\drivers\etc
open the file and at the and add entry like
YOUR_DOMAIN_IP YOUR_SERVER_NAME
e.g.:
12.232.198.44 CANGOO.domain.local
after adding this line i started the office application with a startup error message about certificate, i clicked ok -> the outlook starting continues and then asked me for allowing(adding) a certificate (which i have early created - self signed), i've added the mentioned to Trusted root certification authority folder and VOILA...
everything was solved and worked fine... no need to buy expensive SNA certificates (if u dont want :) )
hope this will help...
FG
-
Sunday, February 19, 2012 12:44 PM
Thank you very much FG!!!
I have been looking for a workaround like this for a while!
.png){kind=spacer}
