Incorrect certificate detected by Outlook connecting to Exchange 2007
Hi There, I have an odd problem, our Outlook clients are not detecting the correct certificate on the Exchange server. Infact they seem to be detecting a local certificate. When I load Outlook (2003, 2007, 2010) it prompts a certificate needs to be accepted, on the 'Security Alert' window it claims the certificate is coming from server.domain.local, but when I look at the certificate details, the certificate is actually to do with the AMI bios that is on the Outlook client PC. There is no AMI bios on the server so I know it is not coming from that machine, and the server was only installed this year so would not expect there to be a certificate expiring before its creation. I can see within CertMgr on the client PC it has the AMI bios certificate and the expirary date matches the certificate trying to be installed with Outlook. I've checked the status of the Certificate on the server and it expires in 2016. What do I need to do in Exchange to make the clients pick up the correct certificate? The server is Windows 2008 R2 with Exchange 2007 SP3. The clients are a mix of XP (SP3) and Windows 7 with a mix of Outlook (2003, 2007, 2010). But all clients do appear to have an AMI bios as they are the same brand of PC, but have different expirary dates co-inciding when we bought the PC's all before 2008. Many Thanks, Richard.Cheers, Rich
June 15th, 2011 7:26am

run get-exchangecertificate on your CAS server copy thumbprint of the correct cert and run the following enable-exchangecertificate -thumbprint --------------- -services IIS,POP,IMAP,SMTPMCSE | MCITP - Server 2008, Exchange 2007, Exchange 2010
Free Windows Admin Tool Kit Click here and download it now
June 15th, 2011 7:36am

Thanks it worked! I feel a little embarrased it was that easy!Cheers, Rich
June 15th, 2011 8:16am

Annoyingly after restarting Outlook we are back to the same scenario. It has somehow reverted back to the old AMI bios certificate. Could there be something stopping Exchange from distributing the correct certificate or is there something else with the client? Do we now need to take the AMI bios out of trusted certificates? Thanks,Cheers, Rich
Free Windows Admin Tool Kit Click here and download it now
June 15th, 2011 9:55am

I've just tried deleting the AMI entry in CertMgr.msc and this has not made any difference, somehow it comes back. Thanks,Cheers, Rich
June 15th, 2011 10:42am

Can you verify that your webservices URLs are set to server.domain.local? The article below shows how to set it but I would query first using the Get- command first to check. Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site" http://support.microsoft.com/kb/940726James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
June 15th, 2011 1:29pm

Hi, From the problem description, all the clients experienced this incorrect certificate detected issue. As we know, towards the certificate detected issue, the warning included three parts: 1. Trust or not; 2. Expire or not; 3. FQDN match or not; From your description, the certificate is trusted and not expired. So the warning is related to the Exchange certificate or the configurations on the Exchange server. Please make sure the FQDN is included in the CertificateDomain. You could use the following command to verify the FQDN included or not: Get-ExchangeCertificate |FL Could you please let me know how many CAS servers are included in your organization? And let me know the detailed URL returned from the Test E-mail AutoConfiguration? If the FQDN is included in the CertificateDomain, you could follow the Jamestechman’s suggestion to verify the settings on your Exchange server are correct or not: Title: Security warning when you start Outlook 2007 and then connect to a mailbox that is hosted on a server that is running Exchange Server 2007 or Exchange Server 2010: "The name of the security certificate is invalid or does not match the name of the site" URL: http://support.microsoft.com/kb/940726 Thx, James Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
June 16th, 2011 3:29am

Hi James, When I ran "get-clientaccessserver |FL" the "AutoDiscoverServiceInternalUri" was pointing to: https://mail.domain.com/autodiscover/autodiscover.xml I have now changed this to: https://server.domain.local/autodiscover/autodiscover.xml I will now do some further testing and get back to you. Many Thanks,Cheers, Rich
Free Windows Admin Tool Kit Click here and download it now
June 17th, 2011 7:24am

Hi James, Appologies, I should have been clearer on the 'Security Alert', they all have a red cross (Trust, Expire, FQDN). However when I changed the AutoDiscoverServiceInternalUri on the 'clientaccessserver' it initially picked up the correct certificate from the server with everything ticked green. But when I rebooted the PC, the certificate went back to red and was for the AMI bios certificate on the local PC again. As mentioned in the first post the AMI bios certificate on the local PC's have all expired, they seem to expire 1 month after they are installed. And as all were purchased before the server existed they will never be in date. I can get some screenshots if required. The output for Get-ExchangeCertificate |FL is as follows: AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessR ule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAcc essRule} CertificateDomains : {server.domain.local, server} HasPrivateKey : True IsSelfSigned : True Issuer : CN=server.domain.local NotAfter : 06/06/2016 16:19:45 NotBefore : 06/06/2011 16:19:45 PublicKeySize : 2048 RootCAType : Registry SerialNumber : 33F92C71839EB0AD4F4EEB1BD55470B9 Services : IMAP, POP, UM, IIS, SMTP Status : Valid Subject : CN=server.domain.local Thumbprint : 0FE26FB0B1B8965D1C4F8F0715C93F0C5D992EE7 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessR ule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAcc essRule} CertificateDomains : {server, server.Domain.local} HasPrivateKey : True IsSelfSigned : True Issuer : CN=server NotAfter : 15/04/2016 18:07:54 NotBefore : 15/04/2011 18:07:54 PublicKeySize : 2048 RootCAType : Registry SerialNumber : 100FCBBCC54EA7B548C251FCEDE75031 Services : IMAP, POP, UM, SMTP Status : Valid Subject : CN=server Thumbprint : 1E7CB493FE6CE0A54BA3F9248C632312805CE693 Thanks, Cheers, Rich
June 17th, 2011 8:07am

Hi James, Appologies, I should have been clearer on the 'Security Alert', they all have a red cross (Trust, Expire, FQDN). However when I changed the AutoDiscoverServiceInternalUri on the 'clientaccessserver' it initially picked up the correct certificate from the server with everything ticked green. But when I rebooted the PC, the certificate went back to red and was for the AMI bios certificate on the local PC again. As mentioned in the first post the AMI bios certificate on the local PC's have all expired, they seem to expire 2 months after they are installed. And as all were purchased before the server existed they will never be in date. I can get some screenshots if required. The output for Get-ExchangeCertificate |FL is as follows: AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessR ule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAcc essRule} CertificateDomains : {server.domain.local, server} HasPrivateKey : True IsSelfSigned : True Issuer : CN=server.domain.local NotAfter : 06/06/2016 16:19:45 NotBefore : 06/06/2011 16:19:45 PublicKeySize : 2048 RootCAType : Registry SerialNumber : 33F92C71839EB0AD4F4EEB1BD55470B9 Services : IMAP, POP, UM, IIS, SMTP Status : Valid Subject : CN=server.domain.local Thumbprint : 0FE26FB0B1B8965D1C4F8F0715C93F0C5D992EE7 AccessRules : {System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAccessR ule, System.Security.AccessControl.CryptoKeyAccessRule, System.Security.AccessControl.CryptoKeyAcc essRule} CertificateDomains : {server, server.Domain.local} HasPrivateKey : True IsSelfSigned : True Issuer : CN=server NotAfter : 15/04/2016 18:07:54 NotBefore : 15/04/2011 18:07:54 PublicKeySize : 2048 RootCAType : Registry SerialNumber : 100FCBBCC54EA7B548C251FCEDE75031 Services : IMAP, POP, UM, SMTP Status : Valid Subject : CN=server Thumbprint : 1E7CB493FE6CE0A54BA3F9248C632312805CE693 Thanks,Cheers, Rich
Free Windows Admin Tool Kit Click here and download it now
June 17th, 2011 8:13am

Here is an image of what the clients are seeing: http://i54.tinypic.com/34e28g6.png As you can see the Thumbprint doesnt even match what the server reports from "Get-ExchangeCertificate |FL" The AMI relates to the BIOS on the client PC's. I've checked certmgr on the server and AMI doesnt exsit. Thanks, Cheers, Rich
June 17th, 2011 9:25am

Just further information as requested. We only have 1 CAS server. Running the Outlook "Test Email Autoconfiguration" reports: "Autodiscover to https://server.domain.local/autodiscover/autodiscover.xml Failed (0x800C8203)" "Received certificate error with no error context. Failing with cert error."Cheers, Rich
Free Windows Admin Tool Kit Click here and download it now
June 17th, 2011 12:15pm

Just further information as requested. We only have 1 CAS server. Running the Outlook "Test Email Autoconfiguration" reports: "Autodiscover to https://server.domain.local/autodiscover/autodiscover.xml Failed (0x800C8203)" "Received certificate error with no error context. Failing with cert error." Cheers, Rich
June 17th, 2011 7:07pm

Hi, From the Get-ExchangeCertificate Output file, there are two Exchange certificates included. Both of them are self-signed certificates. From the snapshot you provided, it doesn’t make sense. I suggest you could follow the suggestions below to verify the status of the AMI certificate on your CAS server: Start à Run à MMC à File à Add/Remove Snap-in à Certificates à Add à Computer Account à Local Computer à Finish à OK. At the same time, we need to do the test on the website to verify the detailed error message you received from the website: https://www.testexchangeconnectivity.com/. Then select the Outlook Autodiscover to verify the issue we are facing now. Please paste the detailed error or warning message you have received on the webpage. Thx, James Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
June 20th, 2011 5:23am

Hi James, Thanks for your reply. I double checked the Certificates on the CAS server but could not find the AMI certificate. This seems to confirm that the AMI certificate is definitely only located on the client PC's. Here are the results of the Exchange Connectivity Test: [START LOG] ExRCA is attempting to test Autodiscover for rich@domain.com. Testing Autodiscover failed. Test Steps Attempting each method of contacting the Autodiscover service. The Autodiscover service couldn't be contacted successfully by any method. Test Steps Attempting to test potential Autodiscover URL https://domain.com/AutoDiscover/AutoDiscover.xml Testing of this potential Autodiscover URL failed. Test Steps Attempting to resolve the host name domain.com in DNS. The host name resolved successfully. Additional Details IP addresses returned: 85.232.44.192 Testing TCP port 443 on host domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Tell me more about this issue and how to resolve it Additional Details A network error occurred while communicating with the remote host. Exception details: Message: The handshake failed due to an unexpected packet format. Type: System.IO.IOException Stack trace: at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslStream.AuthenticateAsClient(String targetHost) at Microsoft.Exchange.Tools.ExRca.Tests.SSLCertificateTest.PerformTestReally() Attempting to test potential Autodiscover URL https://autodiscover.domain.com/AutoDiscover/AutoDiscover.xml Testing of this potential Autodiscover URL failed. Test Steps Attempting to resolve the host name autodiscover.domain.com in DNS. The host name couldn't be resolved. Tell me more about this issue and how to resolve it Additional Details Host autodiscover.domain.com couldn't be resolved in DNS Exception details: Message: The requested name is valid, but no data of the requested type was found Type: System.Net.Sockets.SocketException Stack trace: at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostAddresses(String hostNameOrAddress) at Microsoft.Exchange.Tools.ExRca.Tests.ResolveHostTest.PerformTestReally() . Attempting to contact the Autodiscover service using the HTTP redirect method. The attempt to contact Autodiscover using the HTTP Redirect method failed. Test Steps Attempting to resolve the host name autodiscover.domain.com in DNS. The host name couldn't be resolved. Tell me more about this issue and how to resolve it Additional Details Host autodiscover.domain.com couldn't be resolved in DNS Exception details: Message: The requested name is valid, but no data of the requested type was found Type: System.Net.Sockets.SocketException Stack trace: at System.Net.Dns.GetAddrInfo(String name) at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6) at System.Net.Dns.GetHostAddresses(String hostNameOrAddress) at Microsoft.Exchange.Tools.ExRca.Tests.ResolveHostTest.PerformTestReally() . Attempting to contact the Autodiscover service using the DNS SRV redirect method. ExRCA failed to contact the Autodiscover service using the DNS SRV redirect method. Test Steps Attempting to locate SRV record _autodiscover._tcp.domain.com in DNS. The Autodiscover SRV record wasn't found in DNS. Tell me more about this issue and how to resolve it [/END LOG] Cheers, Rich
June 20th, 2011 2:19pm

Hi, From your confirmation, I understand that the AMI certificate didn’t list on the CAS server. And from the Exchange Connectivity Test, there are some error messages included: --------------------------------------------------------------------------- Attempting to resolve the host name domain.com in DNS. The host name resolved successfully. Additional Details IP addresses returned: 85.232.44.192 Testing TCP port 443 on host domain.com to ensure it's listening and open. The port was opened successfully. Testing the SSL certificate to make sure it's valid. The SSL certificate failed one or more certificate validation checks. Tell me more about this issue and how to resolve it Additional Details A network error occurred while communicating with the remote host. Exception details: Message: The handshake failed due to an unexpected packet format. --------------------------------------------------------------------------- From the information above, we could find that the host name could be resolved and the port 443 was opened. During the checking the SSL certificate, the SSL certificate failed one or more certificate validation checks. And the additional details are related to the network error. The handshake failed due to an unexpected packet format. Could you please let me know whether you have installed some firewall software on your Exchange server such as the ISA server? Since the certificate you provided is the self-signed certificate, we could export the certificate that you are using for the Autodiscover then install the certificate on the client to verify the issue. At the same time, please use the domain-connected PC to see the issue could be reproduced or not. And let me know the result. Thx, James Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
June 23rd, 2011 3:49am

Hi James, Thanks for your reply. The Windows firewall has been disabled during all of this in order to make sure it is not part of the equation. We dont have any teleworkers so do not have those ports forwarded to the server externally. I believe I may now have solved the problem, and it has been a conflict with the Supermicro web based server monitoring software. I had rebooted the server for Windows updates and when it rebooted noticed that Outlook Web Access had stopped working. I finally discovered that the Supermicro monitoring service completely takes over port 80 and can stop IIS from starting the default website. It looks like in the past that after the server had rebooted, IIS was starting before the Supermicro diagnostic service and therefore did not notice a conflict, but the service was potentially doing other things. I'm still keeping this open, but since uninstalling the web monitoring software on Tuesday absolutely no client has had a certificate error, they would appear 4-5 times a day. Fingers crossed this is it! Huge thanks to both James' for your Help. If there are no certificate errors in a weeks time, I will mark this as solved. Many Thanks, Cheers, Rich
June 23rd, 2011 4:18pm

Hi, I can now confirm that after the uninstallation of Supero Doctor III that the certificates on exchange are behaving as they should. We have not had any errors since. This software came pre-installed on our server and whoever installed it put it to port 80, you are supposed to change the port during install I have since found out. Again thanks for your time in trying to resolve this.Cheers, Rich
Free Windows Admin Tool Kit Click here and download it now
June 28th, 2011 12:25pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics