none
Email Notification Problem - could not establish a trust relationship for SSL/TLS secure channel!! RRS feed

  • Question

  • We are setting up a Production FIM.

    The Exchange Server is installed. The FIM Sync Server is installed. The FIM Service/Portal is installed.

    I make a quick test of a Notification to my email address. The parts are: Email Template, a Workflow which calls a Notification activity and an MPR which fires the workflow if the "City" attribute is changed.

    The notification activity starts but I see this in the Event Log: It seems that the notification process retries every 30 seconds.

    System.Web.Services: System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
       at System.Net.Security.SslState.StartSendAuthResetSignal(ProtocolToken message, AsyncProtocolRequest asyncRequest, Exception exception)
       at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)
       at System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32 count, 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.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
       at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)
       at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
       at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size)
       at System.Net.ConnectStream.WriteHeaders(Boolean async)
       --- End of inner exception stack trace ---
       at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.ResourceManagement.WebServices.Mail.Exchange.ExchangeServiceBinding.FindItem(FindItemType FindItem1)
       at Microsoft.ResourceManagement.WebServices.Mail.Exchange.MailChannel.ExchangeMailChannelListener`1.ExchangeMailListener.<OnPollTimerExpired>b__0(Boolean findUnreadItems)
       at Microsoft.ResourceManagement.WebServices.Mail.Exchange.MailChannel.ExchangeMailChannelListener`1.ExchangeMailListener.OnPollTimerExpired(Object state)

    None of this makes much sense to me. Where should I be looking to try and resolve this issue?

    Wednesday, February 27, 2013 8:53 AM

Answers

  • The name on the cert doesn't match your FQDN so Windows doesn't trust it.

    I would as a first step simply update your FIM config to point to the right FQDN - you can edit the Microsoft.ResourceManagement.Service.exe.config file.

    If for some reason you can't do this, try importing the public key portion of the Exchange cert into the trusted roots store on your FIM server and see if that clears this up.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Marked as answer by HaroldHare Tuesday, March 5, 2013 8:02 AM
    Thursday, February 28, 2013 4:47 PM
    Moderator

All replies

  • Probably your Exchange is using self signed certificate or if it is not a self signed it is not trusted on your FIM box. Best way to check it, is to open exchange web service URL in your browser and see if browser will complain about the certificate check what is wrong with it. 

    If it is not trusted - make it trusted or replace with the cert which is trusted in your organization. If it is expired, replace it ... etc.

    There also is a possibility of disabling checks on certificate but then ... why use certs at all.


    Tomek Onyszko, memberOf Predica FIM Team (http://www.predica.pl), IdAM knowledge provider @ http://blog.predica.pl

    Wednesday, February 27, 2013 7:38 PM
  • I see.  It seems Exchange has been installed on a cluster with DNS postbox.domain.com and the certificate is issued by Veritas to postbox.domain.com.

    At FIM install time we gave the Exchange server when prompted as exch01.domain.com which is the fqn of the host hosting Exchange and the install process didnt complain one bit. Its only when we want to use Exchange that FIM complains.

    I am not sure what you mean by "If it is not trusted - make it trusted"

    Do we need to add the certificate issued (I believe Veritas' root CA cert should be already there) into the FIM server's cert store? Anything else?



    Thursday, February 28, 2013 2:20 PM
  • The name on the cert doesn't match your FQDN so Windows doesn't trust it.

    I would as a first step simply update your FIM config to point to the right FQDN - you can edit the Microsoft.ResourceManagement.Service.exe.config file.

    If for some reason you can't do this, try importing the public key portion of the Exchange cert into the trusted roots store on your FIM server and see if that clears this up.


    My Book - Active Directory, 4th Edition
    My Blog - www.briandesmond.com

    • Marked as answer by HaroldHare Tuesday, March 5, 2013 8:02 AM
    Thursday, February 28, 2013 4:47 PM
    Moderator