The ServicePointManager does not support proxies of https scheme (.NET 1.1 SP1)


This was an interesting error that I had to hunt down.  When specifying a proxy server in .NET like this: WebProxy(“https://someproxyserver”) you will get this error.  You will get this error for whatever scheme that you enter before the “://” characters.  For example if you use this: WebProxy(“somescheme://someproxyserver”) Then you will get the error message: The ServicePointManager does not support proxies of somescheme scheme.  The only scheme that is recognized by this class is http.


You will also get this error if you set something like this in your .config file: proxyAddress=”myproxy.somewhere.local:8080″
You MUST list the scheme like this:   proxyAddress=”http://myproxy.somewhere.local:8080″


Discussion – Most organizations do not have an HTTPS Proxy server.  This is not necessary because if SSL communication is required, this communication is between the endpoint server and the Client, not the Proxy and the client.  This does not mean that SSL communication is in anyway not secure through an http Proxy.  The SSL traffic is encrypted and tunneled through the Proxy just fine and this is no less secure than going directly to the SSL based target  (as long as you trust your proxy).  It is only the initial connection to the Proxy that is not over SSL.


 

Comments (14)

  1. ubraun says:

    Hello Jeff, i just fund your interesting statement when searching for an answer for my ssl webservice problem and wondered wether it could be an answer for my problem.

    After testing my webservice client on a http connection (all worked fine) I wanted to switch to a ssl connection and used the wizard of visual studio to generate the proxy classes for the webservice. But it doesn’t work on the first approach.

    Before further digging into the problem the question: is it possible to automatically generate an webservice access class with visual studio 2005 in unmanaged c++ for accessing a webservice (implemented on a linux system) over an ssl connection?

    with best regards,

    Uwe

  2. Jeff Sanders says:

    Hello Uwe,

    This particular post is about the .NET classes.  This does not relate to your situation.

    The unmanaged C++ classes do work fine with an https web server however.  There is even a sample of this: http://msdn2.microsoft.com/en-us/library/s2ya483s(VS.80).aspx

    There are many reasons you may be failing and as the main page says, "This is not a replacement for Microsoft Support, but an area to discuss these technologies."  I would suggest making sure you have no certificate errors when viewing the https service definition using IE 7 as a starting point.  If this does not give any results, then try one of the many discussion groups available as that is what they are designed for.

    Best Regards,

    -Jeff

  3. ubraun says:

    Hello Jeff,

    thanks a lot for your assistance and help – before I asked I looked at the msdn samples and the discussion groups and didn’t find the solution for the problem but a post that it doesn’t work because of ATL design http://www.thescripts.com/forum/thread427882.html .  I thought your post did approve this posting.

    I’m a client programmer and not used to get into such client/server communication problems – espacially when the msdn samples for soap over https all deal with microsoft servers and IASPI-dlls and not with unix/linux and php-nusoap services.

    The fastest way for solving my problem is perhaps to leave the visualstudio assistest webservice-client construction and switch to either gSoap or a commercial package – or what do you think?

    with best regards,

    Uwe

  4. Jeff Sanders says:

    Hi Uwe,

    Ah, I see where you might have been confused.  Same error, totally different Technology.

    You should be able to use the HTTPS protocol using: The MSXML HTTP client (CSoapMSXMLInetClient) or the WinInet-based HTTP client (CSoapWininetClient)

    These two would be preferable for most situations.  User the first if this is used in a service type application, the second for a Desktop application.  If you MUST use the socket implementation (default) then use this sample to get you on your way: http://msdn2.microsoft.com/en-us/library/s2ya483s(VS.80).aspx

    Regards,

    -Jeff

  5. Peter969 says:

    Hi Jeff,

    I’m trapped into a similar issue. I’m running a (Windows service) with a WCF client to get data from a web service. The service runs in a test environment (DMZ) using a proxy (myproxy.somewhere.local:8080) and self-signed SSL certificate for transport security. To bypass the certifcate validation I’m using ServicePointManager.ServerCertificateValidationCallback. Calling the web service is causing the "The ServicePointManager does not support proxies of …" exception. Do you have an idea how to solve this issue? Here is the WCF client configuration.

    <wsHttpBinding>

             <binding name="WSHttpBinding_IDistributorService"  bypassProxyOnLocal="false" proxyAddress="myproxy.somewhere.local:8080" useDefaultWebProxy="true">

               <security mode="TransportWithMessageCredential">

                 <transport clientCredentialType="None" proxyCredentialType="None" realm="" />

                 <message clientCredentialType="UserName" negotiateServiceCredential="true" algorithmSuite="Default" establishSecurityContext="true" />

               </security>

             </binding>

    </wsHttpBinding>

    Any hint is welcome. Thanks in advance.

    Peter

  6. Jeff Sanders says:

    This line tells me that you are using whatever default proxy is set to:

    useDefaultWebProxy="true"

    Try to remove that and use the full URI:

    bypassProxyOnLocal="false" proxyAddress="http://myproxy.somewhere.local:8080&quot; >

    Let me know if that works for you!

  7. Peter969 says:

    Hi Jeff,

    thanks for the fast response.

    I’ve tested your advice. It still does not work. Now I’m getting a ‘Bad Request (400)’ error.

    Peter

  8. Jeff Sanders says:

    Peter,

    Actually my advice did work then.  The request went through.  Now your problem is that the server does not like something about the request you are sending.  You will need to debug this from the WebService side now.  What does the WebService not like?

    Compare a Successful call to your WebService with the Unsuccessful case.  Apply the principles of my blog entry:http://blogs.msdn.com/jpsanders/archive/2008/06/25/troubleshooting-code-that-uses-the-http-protocol.aspx

    If you still cannot determine why you are getting the 400 error, then you should open a support incident with Microsoft.

  9. Gyanendra Sinha says:

    <system.net>

    <defaultProxy enabled=”false” useDefaultCredentials=”true”>

    <proxy bypassonlocal=”True” proxyaddress=”https://”/>

    </defaultProxy>

    </system.net>

    Try This …May be this could resolve your issue..I have faced the same..and this will work for me

  10. Abhishek Srivastava says:

    Thanks Gyanendra, This worked for me also.

  11. Divya Nimavat says:

    Hi Jeff

    I am trying to generate Amazon S3 bucket.

    <?xml version="1.0" encoding="utf-8" ?>

    <configuration>

      <appSettings>

        <add key="AWSAccessKey" value="AKIAI4VFTMHC5******"/>

        <add key="AWSSecretKey" value="***************BNWfWix4Rsykr24SP"/>

        <add key="AWSProfileName" value="development"/>

        <add key="AWSRegion" value="us-west-2" />

      </appSettings>

     <system.net>

       <defaultProxy>

         <proxy usesystemdefault ="False"  proxyaddress="s3-us-west-2.s3.amazonaws.com/:443" bypassonlocal="True" autoDetect="False" />

       </defaultProxy>

     </system.net>

    </configuration>

    And I am getting same error while trying to PUT Bucket "The ServicePointManager does not support proxies with the https scheme"

    Any Help will be Welcome

    Thanks

    Divya

  12. Jeff Sanders says:

    Hi Divya,

    Unfortunately port 443 is HTTPS and that is not supported.  You must use the format specified in the article for the reasons that are also specified in the article.

  13. Divya Nimavat says:

    Many Thanks Jeff,

    I have changed HTTPS to HTTP and it worked.. 🙂

  14. Martin Davies says:

    Thank you very much – explicitly adding the http:// completely solved my problem – the proxy had a subdomain as described above. This has saved me much pain, thanks again!

Skip to main content