Error message when you try to test access from the Microsoft Dynamics CRM E-mail Router: "Incoming Status: Failure - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"

View products that this article applies to.

Symptoms

You configure the Microsoft Dynamics CRM E-mail Router to access a mailbox that is located on a server that is running Exchange Server 2007 or Exchange Server 2010. When you try to test access to the mailbox, you receive the following error message:

Incoming Status: Failure - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. The remote certificate is invalid according to the validation procedure.

This problem occurs if you use self-signed certificates.

↑ Back to the top

Cause

This problem occurs for one or more of the following reasons:
Cause 1 The Microsoft Dynamics CRM E-mail Router uses the Microsoft .NET libraries for certificate validation. The Microsoft Dynamics CRM E-mail Router does not support self-signed certificates.

Cause 2 The URL that you have specified on your Incoming Profile in the Microsoft Dynamcis CRM E-mail Router does not match the URL that you have on your Microsoft Exchange Web Site Certificate.

↑ Back to the top

Resolution

Resolution 1
Implement a signed certificate on the server that is running Exchange Server 2007 or Exchange Server 2010.

Resolution 2
Verify the URL that you have specified on your Incoming Profile in the Microsoft Dynamcis CRM E-mail Router matches the URL that you have on your Microsoft Exchange Web Site Certificate.

To verify the URL you have specified for the Incoming Profile for the Microsoft Dynamics CRM E-mail Router, complete the following steps on the machine where the Microsoft Dynamics CRM E-mail Router is installed:

Click Start, click All programs, click Microsoft Dynamics CRM E-mail Router, and then click Microsoft CRM Email Router.exe.
Click the Configuration Profiles tab, open the Incoming Profile, and then note the URL in the Server field.

Note: To verify your certificate, copy this URL and paste it into an Internet Explorer browser. The certificate is valid if you do not get any errors or warnings.

To check which URL you have on your certificate, follow these steps on your Windows 2008 Microsoft Exchange Server:

Click Start, click Run, type Inetmgr, and then click OK.
Select your server and then click Server Certificates in the Preview Pane.
Open the certificate that is being used for your Microsoft Exchange Server.
Note the URL that is specified on Certificate. Verify that it matches the URL that is specified on your Incoming Profile in the Microsoft Dynamics CRM E-mail Router you found in step 2 above.

To check which URL you have on your certificate, follow these steps on your Windows 2003 Microsoft Exchange Server:

Click Start, click Run, type Inetmgr, and then click OK.
Locate your Exchange Web Site.
Right-click your Exchange Web Site, and then click Properties.
Click the Directory Security tab, click View Certificate, and then note the URL that is specified on Certificate. Verify that it matches the URL that is specified on your Incoming Profile in the Microsoft Dynamics CRM E-mail Router you found in step 2 above.

↑ Back to the top

More Information

There are three primary types of digital certificates that are described as follows:

Self-signed certificates: A self-signed certificate is signed by an application. The subject of the certificate matches the name of the certificate. The issuer and the subject are defined in the certificate. By using a self-signed certificate, some client protocols can use Secure Socket Layer (SSL) for communications.
Windows PKI-generated certificates: A public key infrastructure (PKI) is a system of digital certificates, certification authorities, and registration authorities. The PKI uses public key cryptography to verify and authenticate the validity of each party that is used in an electronic transaction. When you implement a certification authority in an organization that uses the Active Directory directory service, you provide an infrastructure for the certificate life-cycle management, for the renewal, for the trust management, and for the revocation. However, some additional costs are required to deploy the servers and the infrastructure to create and manage Windows PKI-generated certificates. Certificate Services are required to deploy a Windows PKI. You can use the Add or Remove Programs item in Control Panel to install Certificate Services on any servers in the domain.

For more information about the PKI for Windows Server 2003, visit the following Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=19936
For more information about best practices for implementing a Windows PKI, visit the following Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=17800
For more information about how to deploy a Windows-based PKI, visit the following Microsoft Web site:
http://go.microsoft.com/fwlink/?LinkId=17807
Third-party certificates: Third-party certificates or commercial certificates are certificates that are generated by a third-party certification authority or by a commercial certification authority. You purchase these certificates, and then you use the certificates on servers. Client computers and mobile devices do not automatically trust self-signed certificates and Windows PKI-generated certificates. Therefore, you must import the certificates into the trusted root certificate store on client computers and on mobile devices. However, most third-party certificates or commercial certificates already exist in the trusted root certificate store. Therefore, the deployment process is simplified by using third-party certificates or commercial certificates. For larger organizations or for organizations for which you must publicly deploy certificates, using a third-party certificate or a commercial certificate may be a good solution even though you must pay for the certificate. However, third-party certificates or commercial certificates might not be a good solution for small organizations or for medium organizations. You can use the other certificate types that are available for small organizations and for medium organizations.

↑ Back to the top

References

For more information about how to manage SSL for a client access server, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/bb310795(EXCHG.80).aspx

For more information about how to configure SSL certificates to use multiple client access server host names, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/aa995942(EXCHG.80).aspx

For more information about how to install SSL certificates on a Windows mobile powered device, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/aa997575(EXCHG.80).aspx

For more information about how to configure Outlook Web access virtual directories to use SSL, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/bb123583(EXCHG.80).aspx

For more information about certificates that are used in Exchange Server 2007, visit the following Microsoft Web site:

http://technet.microsoft.com/en-us/library/bb851505(EXCHG.80).aspx

↑ Back to the top

Applies to:

↑ Back to the top

Keywords: kbmbsemail, kberrmsg, kbtshoot, kbmbsmigrate, kbprb, kbexpertiseinter, kbmbspartner, kb

↑ Back to the top

Article Info

Article ID	:	954584
Revision	:	1
Created on	:	1/7/2017
Published on	:	1/26/2011
Exists online	:	False
Views	:	329

Microsoft KB Archive Search

Error message when you try to test access from the Microsoft Dynamics CRM E-mail Router: "Incoming Status: Failure - The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel"

Symptoms

Cause

Resolution

More Information

References

Applies to: