locked
Incorrect certificate detected by Outlook connecting to Exchange 2007 RRS feed

  • Question

  • 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
    Wednesday, June 15, 2011 11:21 AM

Answers

  • 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
    • Marked as answer by Rich1983 Tuesday, June 28, 2011 9:21 AM
    Thursday, June 23, 2011 8:11 PM

All replies

  • run get-exchangecertificate on your CAS server

    copy thumbprint of the correct cert and run the following

    enable-exchangecertificate -thumbprint --------------- -services IIS,POP,IMAP,SMTP


    MCSE | MCITP - Server 2008, Exchange 2007, Exchange 2010
    • Marked as answer by Rich1983 Wednesday, June 15, 2011 12:09 PM
    • Unmarked as answer by Rich1983 Wednesday, June 15, 2011 1:46 PM
    Wednesday, June 15, 2011 11:30 AM
  • 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
    Wednesday, June 15, 2011 1:48 PM
  • 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
    Wednesday, June 15, 2011 2:36 PM
  • 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/940726


    James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
    Wednesday, June 15, 2011 5:29 PM
  • 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.
    Thursday, June 16, 2011 7:23 AM
  • 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
    Friday, June 17, 2011 11:18 AM
  • 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
    • Edited by Rich1983 Friday, June 17, 2011 1:25 PM
    Friday, June 17, 2011 12:07 PM
  • 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
    Friday, June 17, 2011 1:25 PM
  • 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
    • Edited by Rich1983 Saturday, June 18, 2011 2:27 PM faulty HTML code
    Friday, June 17, 2011 4:07 PM
  • 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.
    Monday, June 20, 2011 9:22 AM
  • 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

    • Edited by Rich1983 Monday, June 20, 2011 2:50 PM removed MAILTO
    Monday, June 20, 2011 2:48 PM
  • 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.
    Thursday, June 23, 2011 7:48 AM
  • 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
    • Marked as answer by Rich1983 Tuesday, June 28, 2011 9:21 AM
    Thursday, June 23, 2011 8:11 PM
  • 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
    Tuesday, June 28, 2011 9:25 AM