Calendar Connector Web Service - SSL/TLS Problem?

[Ronald Nissley]

So I installed the calendar connector web service and navigated to the
Diagnostics.aspx page. WebService diagnostics pass and all SyncService
diagnostics pass except the _Verify Appointment can be written to
Exchange_ diagnostic, which fails with an error "Could not establish
trust relationship for the SSL/TLS secure channel". Forms based
authentication is disabled (IIS restarted after this change), and the
SSL certificate was issued by a trusted provider. The certificate was
issued for the host name used to access OWA, which is different from
the "proper" FQDN. I've tried changing Exchange.ServerName setting to
the OWA host name and prepending https:// to either host name. The
error messages are different when using the OWA host name. Here is the
error in full (when using the proper [not OWA] FQDN):

Google.GCalExchangeSync.Library.GCalExchangeException: Error writing
appointment ---> 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.CheckCompletionBeforeNextReceive(ProtocolToken
message, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32
count, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32
count, AsyncProtocolRequest asyncRequest) 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.CheckCompletionBeforeNextReceive(ProtocolToken
message, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32
count, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32
count, AsyncProtocolRequest asyncRequest) 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.CheckCompletionBeforeNextReceive(ProtocolToken
message, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32
count, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.ProcessReceivedBlob(Byte[] buffer, Int32
count, AsyncProtocolRequest asyncRequest) 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.CheckCompletionBeforeNextReceive(ProtocolToken
message, AsyncProtocolRequest asyncRequest) at
System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32
count, 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.TlsStream.CallProcessAuthentication(Object
state) at System.Threading.ExecutionContext.runTryCode(Object
userData) at
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode
code, CleanupCode backoutCode, Object userData) at
System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state) 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.Net.HttpWebRequest.GetResponse() at
Google.GCalExchangeSync.Library.WebDav.XmlRequestImpl.IssueRequest(String
url, Method method, String body, HttpHeader[] headers) at
Google.GCalExchangeSync.Library.WebDav.WebDavQuery.IssueRequestIgnoreResponse(String
url, Method method, String body) at
Google.GCalExchangeSync.Library.WebDav.WebDavQuery.CreateAppointment(String
mailboxUrl, Appointment appointment) at
Google.GCalExchangeSync.Library.AppointmentService.WriteAppointments(ExchangeUser
user, List`1 appointments) --- End of inner exception stack trace ---
at
Google.GCalExchangeSync.Library.AppointmentService.WriteAppointments(ExchangeUser
user, List`1 appointments) at
Google.GCalExchangeSync.Tests.Diagnostics.ExchangeTester.WriteAppointment(String
email, DateTime appointmentStart) at
GCalExchangeLookup.Diagnostics.ButtonWriteExchAppt_Click(Object
sender, EventArgs e)

Any ideas?

Thank you,

Ron

[dkuhn]

Is the trusted provider an Internet Root Authority or Internal CA Root
Authority?

If it is internal I suspect that the system account which IIS is
running under does not have the Internal CA in the Trusted Root List.
I would use the certmgr.msc tool to import in the public certs for
your internal trusted root CA into this system/service account.

[Ronald Nissley]

The certificate is not self-signed; it was provided by globessl.com.
The certificate is trusted at the computer account level and this
trust is inherited by normal user and service accounts.

Thank you,

Ron

[Darrell Kuhn ☯]

Ronald,

You can enable a network trace logging which should give more visibility into the TLS session handshake and failure by uncommenting out the following section in your config file. Please just remove the highlighted comment lines from within your config file. Re-run a test and then review the network trace log file created.

<!-- NetTrace Debugging Options -->

<!--

<system.diagnostics>

<trace autoflush="true" />

<sources>

<source name="System.Net">

<listeners>

<add name="TraceFile" />

</listeners>

</source>

</sources>

<sharedListeners>

<add

name="TraceFile"

type="System.Diagnostics.TextWriterTraceListener"

initializeData="c:\google\logs\WebNetTrace.log"

/>

</sharedListeners>

<switches>

<add name="System.Net" value="Verbose" />

</switches>

</system.diagnostics>

-->

Darrell Kuhn
Google Inc.

--
You received this message because you are subscribed to the Google Groups "google-calendar-connectors" group.
To post to this group, send email to google-calend...@googlegroups.com.
To unsubscribe from this group, send email to google-calendar-con...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-calendar-connectors?hl=en.

--
You received this message because you are subscribed to the Google Groups "opensource-google-calendar-connectors" group.
To post to this group, send email to opensource-google-...@google.com.
To unsubscribe from this group, send email to opensource-google-calend...@google.com.
For more options, visit this group at http://groups.google.com/a/google.com/group/opensource-google-calendar-connectors/?hl=en.

[Ronald Nissley]

Darrell,

Thanks for the network trace tip. The information from the trace log
indicates a "certificate name mismatch" when Exchange.ServerName is
set to exchange.ourdomain.local. Indeed, the certificate was generated
for webmail.ourdomain.org (a CNAME pointing to
exchange.ourdomain.local). You can view the trace log in full at
http://pastebin.com/gF3J0Fjv. Incriminating evidence altered to
protect the not-so-innocent.
Do neither the "Verify Free/Busy information can be found in Exchange"
test nor the "Verify Free/Busy can be written to Exchange" tests use
SSL? Those tests pass successfully (verified status). Only the "Verify
Appointment can be written to Exchange" test fails.
If I change the Exchange.ServerName setting to webmail.ourdomain.org,
I no longer see certificate name mismatch errors, instead, I see
unauthorized errors, for the three tests: "Verify Free/Busy
information can be found in Exchange", "Verify Free/Busy can be
written to Exchange", and "Verify Appointment can be written to
Exchange". You can see the trace log in full for a "Verify Appointment
can be written to Exchange" attempt at http://pastebin.com/KSyNcZLb.

Thank you,

Ron

[Ronald Nissley]

> Darrell,
>
> ...the certificate was generated

> for webmail.ourdomain.org (a CNAME pointing to
> exchange.ourdomain.local).

Actually, webmail.ourdomain.org is an A (host) record internally and
externally (we use a split DNS config) and webmail.ourdomain.local is
a CNAME for exchange.ourdomain.local.

[Darrell Kuhn ☯]

Darrell Kuhn
Google Inc.

On Thu, Dec 9, 2010 at 12:46 PM, Ronald Nissley <rnis...@gmail.com> wrote:

Darrell,

Thanks for the network trace tip. The information from the trace log
indicates a "certificate name mismatch" when Exchange.ServerName is
set to exchange.ourdomain.local. Indeed, the certificate was generated
for webmail.ourdomain.org (a CNAME pointing to
exchange.ourdomain.local). You can view the trace log in full at
http://pastebin.com/gF3J0Fjv. Incriminating evidence altered to
protect the not-so-innocent.
Do neither the "Verify Free/Busy information can be found in Exchange"
test nor the "Verify Free/Busy can be written to Exchange" tests use
SSL? Those tests pass successfully (verified status). Only the "Verify
Appointment can be written to Exchange" test fails.

The trace appears to only include the attempt to write appointment to calendar. This test is not valid for your setup so ignore that test please. However, it may indicate the service account you are using does not have the "recieve as" permissions required. Can you confirm this? NOTE: Some default groups like Domain Admins have deny rights to receive as by default so if this user is in any of these default groups this could be the reason you are getting access denied.  

If you still are getting errors writing free/busy data send me the network trace log for that, it will hopefully reveal more data if the issue is beyond access rights

 

If I change the Exchange.ServerName setting to webmail.ourdomain.org,
I no longer see certificate name mismatch errors, instead, I see
unauthorized errors, for the three tests: "Verify Free/Busy
information can be found in Exchange", "Verify Free/Busy can be
written to Exchange", and  "Verify Appointment can be written to
Exchange". You can see the trace log in full for a "Verify Appointment
can be written to Exchange" attempt at http://pastebin.com/KSyNcZLb.

Thank you,

Ron