0

In VS2019, when I attempt to add a web reference to a wsdl provided by an API ([url]/file.wsdl - which is different from what I'm used to, that being [url]/?wsdl) I can see the wsdl itself (after selecting the appropriate cert), but I get this error in the area where it shows the "Web services found at this URL":

There was an error downloading '[url]/file.wsdl/$metadata'. The request was aborted: Could not create SSL/TLS secure channel.

I can navigate in a browser to both the wsdl file AND the metadata url (although that metadata url shows me just "SOAP-ENV:Server"). So I am reasonably sure it's not a certificate issue (which we certainly did have, but seem to have since been resolved). I've never seen this one before. All questions related to this topic here seem to be cert related or, in the case of $metadata request failures, a different error (404 for example).

user621713
  • 13
  • 5
  • Is the service running as Admin? The app is probably not running with the same account that you are using to browse to folder. – jdweng Sep 06 '19 at 15:51
  • By service do you mean the API? That's a 3rd party vendor. I've also tried running VS as admin and get the same error – user621713 Sep 06 '19 at 16:08
  • Why is there a dollar sign in $metadata. The dollar sign may be the error. Does the API require the dollar sign? – jdweng Sep 06 '19 at 16:43
  • The reference I attempt to add is simply [url]/file.wsdl . VS seems to go after $metadata by itself. – user621713 Sep 06 '19 at 17:19
  • Interesting. I'm guessing. But it looks like the API opened the file to look for something it didn't find. SSL/TLS looks at the certificate to make a secure connection. did you check the certificate for the expiration date? Maybe it is pulling the wrong certificate or the certificate isn't valid. – jdweng Sep 06 '19 at 17:26
  • Certificates definitely seem valid- I can get to the wsdl just fine. – user621713 Sep 06 '19 at 18:13
  • You can check with vendor to see if certificates are good. Does vendor have app that you can use to check if his tool works? I do not know if using a sniffer may help. – jdweng Sep 06 '19 at 19:11
  • The service is in active use now using an older version of this code. I'm trying to use new added functionality so I'm re-adding the web reference so it will pick up the new classes. – user621713 Sep 06 '19 at 21:40
  • The default option in Net often changes from versions. So I suspect that you are using a new version of Net. Are you running service on same machine that it is working. The best way of debugging is to use a sniffer and compare 1st request of working and non working app. Sniffer can be on any machine in subnet of either client or server. Since you are using TLS/SSL the connection uses TCP to go secure as well as using HTTP. – jdweng Sep 06 '19 at 22:08
  • I'm running VS2019 so my next step is to try a downgrade to 2015 (or 12 if I can find it) and see if that works. The app that's using this service is working on the machine I'm developing on, it's just trying to update the wsdl reference where the issue happens. – user621713 Sep 09 '19 at 13:41
  • Using a sniffer, I see all traffic going to the wsdl host is indeed using TLS 1.2, so it's not a matter of some part of this update chain using the incorrect security. I'm wondering if this error is masking some other error in the request/response. – user621713 Sep 09 '19 at 14:26
  • Did you try sniffer on working machine so you can compare working and non working? The sniffer can be on any machine in same subnet as either the client or server. – jdweng Sep 09 '19 at 14:51
  • I also attempted creating the reference using an older VS version, that got me a different error: There was an error downloading [wsdl file]. The underlying connection was closed: An unexpected error occurred on a receive. The client and server cannot communicate, because they do not possess a common algorithm. That got me to this SO article: https://stackoverflow.com/questions/48629377/visual-studio-2012-issues-with-web-service-after-disabling-tls-1-0 and I made those registry changes, but still no joy. – user621713 Sep 09 '19 at 15:35
  • That solution is only for TLS 1.0 which is obsolete and current version is TLS 1.1. So the fix was to use Net 4.0 which supported TLS 1.0. – jdweng Sep 09 '19 at 15:39
  • I've tried it using every .NET version available on that machine, from 2.0 on up and I get he same error every time, unfortunately. Thanks, by the way, for your continued interest in this one. – user621713 Sep 09 '19 at 15:58
  • Can you sniff the working code and at least get the old parameters to match with new code. – jdweng Sep 09 '19 at 16:00
  • Not sure I understand- the issue isn't so much communicating with the api itself, just the hosted wsdl. – user621713 Sep 09 '19 at 17:29
  • The communication is using http so you can capture on sniffer. It is not the communications it is the headers in the request which can be viewed with the sniffer. – jdweng Sep 09 '19 at 18:03
  • So communicating with the API happens fine- the older version of this code works fine. I just need to update the web reference in my project so I can get access to new fields. – user621713 Sep 10 '19 at 17:54
  • Then why are you getting 404 (https://developer.mozilla.org/en-US/docs/Web/HTTP/Status)? Is old and/or new running as an admin? – jdweng Sep 10 '19 at 18:43
  • Sorry for the confusion, the 404 I referenced in the question is that other people who had an error downloading from the $metadata endpoint got 404's, where I get this TLS error – user621713 Sep 10 '19 at 18:58

0 Answers0