El esquema de URI proporcionado 'https' no es válido; esperado 'http'. Nombre del parámetro: vía

Estoy tratando de hacer un servicio WCF sobre basicHttpBinding para usarlo sobre https. Aquí está mi web.config:

<!-- language: xml -->
<service behaviorConfiguration="MyServices.PingResultServiceBehavior"
         name="MyServices.PingResultService">
    <endpoint address="" 
              binding="basicHttpBinding" 
              bindingConfiguration="defaultBasicHttpBinding"
              contract="MyServices.IPingResultService">
        <identity>
            <dns value="localhost" />
        </identity>
    </endpoint>
    <endpoint address="mex" 
              binding="mexHttpBinding" 
              contract="IMetadataExchange" />
</service>
...

<bindings>
  <basicHttpBinding>
    <binding name="defaultBasicHttpBinding">
      <security mode="Transport">
        <transport clientCredentialType="None"/>
      </security>
    </binding>
  </basicHttpBinding>
</bindings>
...
<behaviors>
  <serviceBehaviors>
    <behavior name="MyServices.UpdateServiceBehavior">
      <serviceMetadata httpsGetEnabled="true" />
      <serviceDebug includeExceptionDetailInFaults="true" />
    </behavior>
  </serviceBehaviors>
</behaviors>

Me estoy conectando usando WCFStorm, que puede recuperar todos los metadatos correctamente, pero cuando llamo al método real obtengo:

El esquema de URI proporcionado 'https' no es válido; esperado 'http'. Nombre del parámetro: vía

Intente agregar credenciales de mensaje en su aplicación. Configure como:

<bindings> 
<basicHttpBinding> 
<binding name="defaultBasicHttpBinding"> 
  <security mode="Transport"> 
    <transport clientCredentialType="None" proxyCredentialType="None" realm=""/> 
    <message clientCredentialType="Certificate" algorithmSuite="Default" />
  </security> 
</binding> 
</basicHttpBinding> 
</bindings> 

Agregando esto como respuesta, solo porque no puede hacer mucho formato elegante en los comentarios.
Tuve el mismo problema, excepto que estaba creando y vinculando mi cliente de servicio web completamente en código.
La razón es que la DLL se estaba cargando en un sistema, lo que prohibió el uso de archivos de configuración.

Aquí está el código, ya que necesitaba actualizarse para comunicarse a través de SSL ...

Public Function GetWebserviceClient() As WebWorker.workerSoapClient
    Dim binding = New BasicHttpBinding()
    binding.Name = "WebWorkerSoap"
    binding.CloseTimeout = TimeSpan.FromMinutes(1)
    binding.OpenTimeout = TimeSpan.FromMinutes(1)
    binding.ReceiveTimeout = TimeSpan.FromMinutes(10)
    binding.SendTimeout = TimeSpan.FromMinutes(1)

    '// HERE'S THE IMPORTANT BIT FOR SSL
    binding.Security.Mode = BasicHttpSecurityMode.Transport

    Dim endpoint = New EndpointAddress("https://myurl/worker.asmx")

    Return New WebWorker.workerSoapClient(binding, endpoint)
End Function

Cambiar de

<security mode="None">

a

<security mode="Transport">

en su archivo web.config. Este cambio le permitirá usar https en lugar de http

¿Está ejecutando esto en Cassini (vs dev server) o en IIS con un certificado instalado? He tenido problemas en el pasado tratando de conectar puntos finales seguros en el servidor web de desarrollo.

Aquí está la configuración de enlace que me ha funcionado en el pasado. En lugar de basicHttpBinding, lo usa wsHttpBinding. No sé si eso es un problema para ti.

<!-- Binding settings for HTTPS endpoint -->
<binding name="WsSecured">
    <security mode="Transport">
        <transport clientCredentialType="None" />
        <message clientCredentialType="None"
            negotiateServiceCredential="false"
            establishSecurityContext="false" />
    </security>
</binding>

y el punto final

<endpoint address="..." binding="wsHttpBinding"
    bindingConfiguration="WsSecured" contract="IYourContract" />

Además, asegúrese de cambiar la configuración del cliente para habilitar la seguridad de transporte.

Tuve la misma excepción en un custom bindingescenario. Cualquiera que use este enfoque, puede verificar esto también.

En realidad estaba agregando la referencia de servicio de un local WSDL archivo. Se agregó con éxito y se agregó el enlace personalizado requerido al archivo de configuración. Sin embargo, el servicio real era https; no http. Así que cambié el elemento httpTransport como httpsTransport. Esto solucionó el problema

<system.serviceModel>
<bindings>

  <customBinding>
    <binding name="MyBindingConfig">

      <textMessageEncoding maxReadPoolSize="64" maxWritePoolSize="16"
        messageVersion="Soap11" writeEncoding="utf-8">
        <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
          maxBytesPerRead="4096" maxNameTableCharCount="16384" />
      </textMessageEncoding>

      <!--Manually changed httpTransport to httpsTransport-->
      <httpsTransport manualAddressing="false" maxBufferPoolSize="524288"
        maxReceivedMessageSize="65536" allowCookies="false" authenticationScheme="Anonymous"
        bypassProxyOnLocal="false" 
        decompressionEnabled="true" hostNameComparisonMode="StrongWildcard"
        keepAliveEnabled="true" maxBufferSize="65536" 
        proxyAuthenticationScheme="Anonymous"
        realm="" transferMode="Buffered" unsafeConnectionNtlmAuthentication="false"
        useDefaultWebProxy="true" />
    </binding>
  </customBinding>

</bindings>

<client>
  <endpoint address="https://mainservices-certint.mycompany.com/Services/HRTest"
    binding="customBinding" bindingConfiguration="MyBindingConfig"
    contract="HRTest.TestWebserviceManagerImpl" name="TestWebserviceManagerImpl" />
</client>


</system.serviceModel>

Referencias

1. WCF con custombinding en http y https

Tuve exactamente el mismo problema que el OP. Mi configuración y situación eran idénticas. Finalmente lo reduje a un problema en WCFStorm después de crear una referencia de servicio en un proyecto de prueba en Visual Studio y confirmar que el servicio estaba funcionando. En Storm, debe hacer clic en la opción de configuración "Configuración" (NO LA "Configuración del cliente"). Después de hacer clic en eso, haga clic en la pestaña "Seguridad" en el cuadro de diálogo que aparece. Asegúrese de que "Tipo de autenticación" esté configurado en "Ninguno" (el valor predeterminado es "Autenticación de Windows"). Presto, funciona! Siempre pruebo mis métodos en WCFStorm mientras los estoy construyendo, pero nunca he intentado usarlo para conectarme a uno que ya está configurado en SSL. ¡Espero que esto ayude a alguien!

Me encontré con el mismo problema, así es como resultó mi solución al final:

        <basicHttpsBinding>
            <binding name="VerificationServicesPasswordBinding">
              <security mode="Transport">
              </security>
            </binding>
            <binding name="VerificationServicesPasswordBinding1" />
        </basicHttpsBinding>

Básicamente reemplacé cada aparición de Http con Https. Puede intentar agregar ambos si lo prefiere.

Si hace esto programáticamente y no en web.config es:

new WebHttpBinding(WebHttpSecurityMode.Transport)

Es bueno recordar que los archivos de configuración se pueden dividir en archivos secundarios para facilitar los cambios de configuración en diferentes servidores (desarrollo / demostración / producción, etc.), sin tener que volver a compilar código / aplicación, etc. Por ejemplo, los usamos para permitir que los ingenieros en el sitio realizar cambios de punto final sin tocar realmente los archivos 'reales'.

El primer paso es mover la sección de enlaces fuera de la aplicación WPF.Config en su propio archivo separado.

La sección de comportamientos está configurada para permitir tanto http como https (no parece afectar la aplicación si ambos están permitidos)

<serviceMetadata httpsGetEnabled="true" httpGetEnabled="true" />

Y trasladamos la sección de enlaces a su propio archivo;

 <bindings configSource="Bindings.config" /> 

En el archivo bindings.config cambiamos la seguridad según el protocolo

  <!-- None = http:// -->
  <!-- Transport = https:// -->
  <security mode="None" >

Ahora los ingenieros en el sitio solo necesitan cambiar el archivo Bindings.Config y el Client.Config donde almacenamos la URL real para cada punto final.

De esta manera, podemos cambiar el punto final de http a https y viceversa para probar la aplicación sin tener que cambiar ningún código.

Espero que esto ayude.

Para volver a cerrar la pregunta en el OP:

Me estoy conectando [a un servicio WCF] usando WCFStorm que puede recuperar todos los metadatos correctamente, pero cuando llamo al método real obtengo:

El esquema de URI proporcionado 'https' no es válido; esperado 'http'. Nombre del parámetro: vía

Los tutoriales de WCFStorm abordan este problema al trabajar con IIS y SSL .

Su solución funcionó para mí:

1. Para corregir el error, genere una configuración de cliente que coincida con la configuración del servicio wcf. La forma más fácil de hacer esto es con Visual Studio.

   • Abra Visual Studio y agregue una referencia de servicio al servicio. VS generará un archivo app.config que coincida con el servicio

   • Edite el archivo app.config para que WCFStorm pueda leerlo. Consulte Carga de archivos de App.config del cliente . Asegúrese de que los atributos de punto final / @ nombre y punto final / @ contrato coincidan con los valores de wcfstorm.

2. Cargue el archivo app.config modificado en WCFStorm [usando el botón de la barra de configuración del cliente].

3. Invocar el método. Esta vez, la invocación del método ya no fallará

El último punto (1) en efecto significa eliminar el prefijo de espacio de nombres que VS antepone al atributo del contrato de punto final, por defecto "ServiceReference1"

<endpoint ... contract="ServiceReference1.ListsService" ... />

así que en la app.config que carga en WCFStorm que desea para ListsService:

<endpoint ... contract="ListsService" ... />

Necesitaba los siguientes enlaces para que el mío funcionara:

        <binding name="SI_PurchaseRequisition_ISBindingSSL">
          <security mode="Transport">
            <transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
          </security>
        </binding>

¡wsHttpBinding es un problema porque silverlight no lo admite!