Applies to: Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-09-13

This topic explains how to troubleshoot Event 1037 and Event 2019. These events are associated with direct trust certificates.

Event 1037 and Event 2019 are Warning events that indicate that a problem occurred when Microsoft Exchange tried to validate an internal transport certificate (also referred to as a direct trust certificate) on the computer on which the events occurred. In Microsoft Exchange Server 2007, direct trust means that the presence of the certificate in the Active Directory directory service or Active Directory Application Mode (ADAM) directory service validates the certificate. Active Directory is considered a trusted storage mechanism. When direct trust is used, it doesn't matter if the certificate is self-signed or signed by a certification authority.

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

The problem that is indicated by Event 1037 and Event 2019 is caused by one or more of the following conditions:

Before You Begin

To perform this procedure, the account you use must be delegated the following:

To run the any of these cmdlets or Filemon on a computer that has the Edge Transport server role installed, you must log on by using an account that is a member of the local Administrators group on that computer.

For more information about permissions, delegating roles, and the rights that are required to administer Exchange 2007, see Permission Considerations.

Procedure

To resolve the Warning events, do one or more of the following

  • Make sure that the SMTP service is enabled on the certificate.

    Run the following cmdlet in the Exchange Management Shell.

    Get-ExchangeCertificate | fl *

    Note:
    If you are running Exchange Server 2007 Service Pack 1 or later, do not include the asterisk (*) on the command argument.

    The output will show details of all certificates that are installed on the computer.

    • If the value of the IsSelfSign attribute is True, the certificate is the self-signed certificate installed by Microsoft Exchange. You can have more than one self-signed certificate installed on the server. However, only the valid certificate with the most recent timestamp will be used.

    • If the value of the IsSelfSign attribute is False, the certificate is a third-party certificate or a customized certificate.

    If the Services attribute does not include the value SMTP, run the following cmdlet in the Exchange Management Shell.

    Copy Code 
    Enable-ExchangeCertificate -Thumbprint <insert_certificate_thumbprint> -Services:SMTP
    Note:
    This command will append SMTP to all services that are 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 account 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 2007 was installed.

    Note:
    Filemon can also be used to determine whether this is a permissions problem.

  • Start Filemon and capture the occurrence of the error. Review the resulting log file for any access denied events. Verify that the parameters that are configured in the local DNS configuration match the criteria that are being used in the validation process for the direct trust certificates. The local DNS configuration should be compared to the self-signed certificate that is installed by Microsoft Exchange because that certificate is required for direct trust purposes. The validation process for the internal transport certificates checks the following DNS configuration settings:

    • DnsFullyQualifiedDomainName

    • DnsHostName

    • DnsPhysicalFullyQualifiedDomainName

    • DnsPhysicalHostName

    You can review the criteria for the certificate by using Exchange Troubleshooting Assistant tracing. To do this, use the following components and tags:

    • Common\Certificate

    • NetworkingLayer\Certificate

    • Transport\Certificate

    The Exchange Troubleshooting Assistant trace generates output that can help you determine whether the fully qualified domain name (FQDN) matches the domains configured on the self-signed certificate. If the FQDN does not match, it is likely configured incorrectly. In this scenario, you should try to determine what location the certificate is pulling the data from.

  • If the Exchange server is running in an NLB environment, an unexpected FQDN may be added during the validation process for the direct trust certificates. 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