c# - una - El esquema URI proporcionado ''https'' no es válido; Se esperaba ''http''. Nombre del parámetro: via
no se pudo establecer una relación de confianza para el canal seguro ssl/tls con la autoridad (12)
Estoy tratando de hacer un servicio WCF sobre basicHttpBinding para ser usado 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 URI proporcionado ''https'' no es válido; Se esperaba ''http''. Nombre del parámetro: via
¿Está ejecutando esto en la Cassini (vs servidor de dev) o en IIS con un certificado instalado? He tenido problemas en el pasado al tratar de conectar puntos finales seguros en el servidor web dev.
Aquí está la configuración de enlace que me ha funcionado en el pasado. En lugar de basicHttpBinding , 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.
Agregando esto como una respuesta, solo porque no puedes hacer un formateo elegante en los comentarios.
Tuve el mismo problema, excepto que estaba creando y enlazando 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 que necesitaba ser actualizado 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 te permitirá usar https en lugar de http
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 (dev / demo / production, etc.), sin tener que volver a compilar el código / aplicación, etc. realice cambios de punto final sin tocar realmente los archivos ''reales''.
El primer paso es mover la sección de enlaces de WPF App.Config a su propio archivo separado.
La sección de comportamientos está configurada para permitir tanto http como https (no parece tener un efecto en la aplicación si ambos están permitidos)
<serviceMetadata httpsGetEnabled="true" httpGetEnabled="true" />
Y movemos la sección de enlaces a su propio archivo;
<bindings configSource="Bindings.config" />
En el archivo bindings.config cambiamos la seguridad basada en 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 volver a probar la aplicación sin tener que cambiar ningún código.
Espero que esto ayude.
Intente agregar credenciales de mensajes en su app.config como:
<bindings>
<basicHttpBinding>
<binding name="defaultBasicHttpBinding">
<security mode="Transport">
<transport clientCredentialType="None" proxyCredentialType="None" realm=""/>
<message clientCredentialType="Certificate" algorithmSuite="Default" />
</security>
</binding>
</basicHttpBinding>
</bindings>
Necesitaba los siguientes enlaces para hacer que el mío funcione:
<binding name="SI_PurchaseRequisition_ISBindingSSL">
<security mode="Transport">
<transport clientCredentialType="Basic" proxyCredentialType="None" realm="" />
</security>
</binding>
Para recapitular 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 URI proporcionado ''https'' no es válido; Se esperaba ''http''. Nombre del parámetro: via
Los tutoriales de WCFStorm solucionan este problema en Trabajar con IIS y SSL .
Su solución funcionó para mí:
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 hacerlo 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. Por favor, vea la carga de los archivos de aplicación de cliente . Asegúrese de que los atributos de endpoint / @ name y endpoint / @ contract coincidan con los valores en wcfstorm.
Cargue la aplicación modificada .config en WCFStorm [usando el botón de barra de herramientas de configuración del cliente].
Invoca el método. Esta vez la invocación del método ya no fallará
La última viñeta del elemento (1) en efecto significa eliminar el prefijo de espacio de nombres que VS anula ante el atributo de contrato de punto final, de forma predeterminada "ServiceReference1"
<endpoint ... contract="ServiceReference1.ListsService" ... />
por lo tanto, en la aplicación.config que carga en WCFStorm que desea para ListsService:
<endpoint ... contract="ListsService" ... />
Se 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 sustituí cada aparición de Http con Https. Puedes intentar agregar ambos si lo prefieres.
Si haces esto programáticamente y no en web.config es:
new WebHttpBinding(WebHttpSecurityMode.Transport)
Tuve el mismo problema exacto 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 de 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 cuando los estoy desarrollando, pero nunca he intentado usarlos para conectarse a uno que ya se ha configurado en SSL. ¡Espero que esto ayude a alguien!
Tuve la misma excepción en un escenario de custom binding . Cualquiera que use este enfoque, puede verificar esto también.
En realidad estaba agregando la referencia de servicio de un archivo local WSDL . Se agregó correctamente y se agregó un enlace personalizado al archivo de configuración. Sin embargo, el servicio real era https; no http. Así que cambié el httpTransport elemet 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
wsHttpBinding es un problema porque Silverlight no lo admite.