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="https://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
Anonymous
August 09, 2007
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, UweAnonymous
August 10, 2007
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, -JeffAnonymous
August 15, 2007
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, UweAnonymous
August 15, 2007
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, -JeffAnonymous
March 12, 2009
The comment has been removedAnonymous
March 13, 2009
The comment has been removedAnonymous
March 13, 2009
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. PeterAnonymous
March 13, 2009
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.Anonymous
September 26, 2009
<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 meAnonymous
June 13, 2014
Thanks Gyanendra, This worked for me also.Anonymous
April 14, 2015
The comment has been removedAnonymous
April 14, 2015
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.Anonymous
April 16, 2015
Many Thanks Jeff, I have changed HTTPS to HTTP and it worked.. :)Anonymous
December 06, 2015
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!Anonymous
June 13, 2017
Thank you Jeff!!! Solved my problem in less than 5 minutes!