This Warning event indicates that a problem occurred when attempting to validate an internal transport certificate (also referred to as a direct trust certificate) on this computer. In Microsoft Exchange Server 2010, direct trust is the authentication functionality for which the presence of the certificate in the Active Directory directory service or Active Directory Lightweight Directory Service (AD LDS) validates the certificate. Active Directory is considered a trusted storage mechanism.

By default, Exchange uses a self-signed certificate installed by Exchange server instead of using a third-party custom certificate. However, you can use a custom certificate for direct trust.

This problem is caused by one or more of the following conditions:

• The SMTP service is not enabled on the certificate. By default, self-signed internal transport certificates have the SMTP service enabled. Therefore, it is more likely that the SMTP service may not be enabled if a custom certificate that is being used for direct trust is installed.
  
  
• The Network Service account may not have the correct permissions on the machine keys.
  
  
• The host name query in the certificate selection process may fail because of incorrect DNS or machine name configuration.
  
  
• The Hub Transport server role is configured to use Network Load Balancing (NLB). The Hub Transport server role is not supported in a cluster or NLB configuration for the purposes of Exchange Server authentication for scenarios such as communication between Hub Transport servers. Using NLB may cause the host name query to fail during certificate validation.
  
  

To resolve this warning, do one or more of the following:

• Make sure that the SMTP service is enabled on the certificate.
  
  Run the following Exchange Management Shell command: Get-ExchangeCertificate | fl
  
  The output will show details of all certificates that are installed on the computer.
  
  
  • If the value of the IsSelfSign attribute is True, this is the self-signed certificate installed by Exchange. You can have more than one self-signed certificate installed on the server. However, only the most recent timestamp would be considered.
    
    
  • If the value of the IsSelfSign attribute is False, the certificate is a third-party or custom certificate.
    
    
  If the Services attribute does not include the value SMTP, run the following Exchange Management Shell command:
  
  Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP
  
  Note   This command will append SMTP to any services already enabled on the certificate. It will not remove any existing services.
  
  
• Determine whether the Network Service account has the correct permissions. Make sure that the Network Service has Read permissions on all the keys in the following directory: C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, where C:\ is the directory to which Exchange 2010 was installed.
  
  Note   Filemon can also be used to determine whether this is a permissions issue.
  
  Start Filemon and capture the occurrence of the error. Review the resulting log file for any access denied events. Verify that the parameters configured in DNS machine configuration match the criteria being used in the internal transport certificate validation process. The DNS machine configuration should be checked against the self-signed certificate installed by Exchange server as this is the certificate we expect to use for direct trust purposes. 
  
  
• If the Exchange server is running in an NLB environment, an unexpected FQDN may be added during the certificate validation process. If you notice an unexpected domain, check the NLB configuration to see whether the unexpected domain is configured there. If the NLB configuration contains the unexpected FQDN, modify the NLB configuration so that it does not cause the certificate validation to fail.
  
  

For more information, see the following topics:

• Understanding TLS Certificates
  
  
• Troubleshooting Certificate Validation Errors
  
  

If you are not already doing so, consider running the Exchange tools created to help you analyze and troubleshoot your Exchange environment. These tools can help make sure that your configuration aligns with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. To run these tools, go to the Toolbox node of the Exchange Management Console. To learn more about these tools, see Managing Tools in the Toolbox.