none
The remote certificate is invalid according to the validation procedure

    Question

  • Hello,

    I am trying to access Exchange using the Exchange Web Services.

    I am using visual studio 2008. I First tried to create a reference using wcf. It worked but the proxy generated did not had a ExchangeServiceBinding but ExchangeServicePortType. Then I tried using web reference and the proxy generated was good.

    I don't really get why the proxies are different. Any guess?

    When I try to use the proxy (the one generated with web reference), I get the following exception:

    The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

    and the inner exception:

    The remote certificate is invalid according to the validation procedure.

    I use the following to create the proxy:

    Code Snippet

    ExchangeServiceBinding esb = new ExchangeServiceBinding();

    esb.Url = @"https://......";

    esb.Credentials = new NetworkCredential(...);



    The exception is thrown when I try to use any of the proxy method.

    I understand why the exception is thrown. The certificate is not totally valid (problem between the name of the page and the name of the certificate...). However, I would like to use it. How can it be achieved?


    Thursday, February 14, 2008 1:43 PM

Answers

  • I could find a solution. Probably not a good one but it works for me:

    Code Snippet

    ServicePointManager.ServerCertificateValidationCallback = (obj,certificate,chain,errors) => true;



    Thursday, February 14, 2008 3:18 PM

All replies

  • I could find a solution. Probably not a good one but it works for me:

    Code Snippet

    ServicePointManager.ServerCertificateValidationCallback = (obj,certificate,chain,errors) => true;



    Thursday, February 14, 2008 3:18 PM
  •  

    The reason you are getting the SSL error is that likely your exchange server has a self signed certificate, which of course is not trusted by the client since the root certificate is issued by the machine rather than one of the "trusted" root cert authorities.  For testing purposes, doing the above is fine (you are just saying that I trust the cert regardless), but typically when you deploy you need to make sure to install a valid certificate on the CAS box whether issued by a well know trusted authority or by an internal cert authority for your company if this is an intranet app.  Then you will not need to intercept the cert validation callback anymore.

     

    Regarding the differences between ExchangeServiceBinding and ExchangeServicePortType, the former is generated by VS 2005 using the asp.net services stack.  The latter is generated by the WCF stack.  Both end up doing the same thing (convert proxy class instances to XML and back).  Anyways, the biggest difference that you will see is that when building the WCF proxy, you will need to specify an endpoint (address, binding, contract) via the Services Configuration Editor tool.  Also while in there, you will likely want to increase the various quotas so that large EWS responses don't cause the WCF proxy to throw.

    Thursday, February 14, 2008 3:42 PM
  • Hello David,

    Thank you for your answer.

    You're right about the certificate things.

    Which proxy would you advice to use? Which is the easier to use?

    I haven't been able to find much documentation.

    I found http://msdn2.microsoft.com/en-us/library/bb409286(EXCHG.80).aspx about ExchangeServiceBinding. Too bad there are no code sample, only the soap message . And nothing about ExchangeServicePortType.
    Thursday, February 14, 2008 3:53 PM
  • I have done a bunch with the ASP.Net stack which can still be generated via the WSDL.exe tool on the command line in VS2008.  In fact, all of the proxy code in the EWS book was done using the ASP.Net generated proxies.  However, since then I have started using the WCF generated proxies.  Both work fine, although there are a couple things that you have to get used to (such as the Services Configuration Editor), the service model stuff in the config files and whatnot.  In addition, with the WCF generated proxies, you end up creating objects that represent the entire SOAP envelope including the SOAP headers and passing that to the port type methods while with the ASP.Net proxies, you are passing objects that represent the SOAP body to the proxy method and the SOAP headers are exposed as properties on the binding.

     

    There are several good books out on WCF that cover client proxy generation.  WCF Unleashed is one of my favorites.

     

    Both the WCF and ASP.Net generated proxies use XmlSerialization for EWS since we have attributes galore in our schema, so for the most part all of the various EWS proxy types will be exactly the same.  The main difference is with the portType vs binding and the endpoint configuration/xml files.

     

    (Warning:  Marketing opportunity)  The EWS book (Inside Microsoft Exchange Server 2007 Web Services by MSPress) covers the ASP.Net proxies in great detail with tons of example code, compelling stories, beautiful graphics and reusable classes to make your life much better Smile  Printed on crisp, white paper in a font that is easy on the eyes, this book will give you years of enjoyment and is an heirloom you can pass down for generations to come.  Or something like that.

     

     

    Friday, February 15, 2008 3:58 PM
  • Hi David,


    based on your book, the proxy used for push notification is fixed one. This port however, I cannot create because windows 2003 server firewall is not enabled so I cannot add new port to the server. Any advise?
    Wednesday, April 08, 2009 3:58 AM