WE have a working Windows Server 2016 server running https. Our application is NOT a web app but a WPF app running https. We upgraded to Windows 2019 server and now https is not working. The application does come up but after I put in my username and password, I get the above error. I looked at all the posts before but nothing has worked.
In our web.config we do set SSL key to true.
<add key="EnableSSL" value="true" />
<serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" />
We do not have any bindings section in our web.config file.
I have the bindings set correctly in IIS with a valid cert. I am able to run up the local host using https. WE do have a webapp on the 2019 server that is running fine with https.
Related
I need help setting up my Azure virtual machine to allow connection to my WCF website service. Please, I am just missing something simple relative to Azure.
I get this error:
"There was no endpoint listening at http://mydomainname.com/registrations.svc that could accept the message"
I have set up the HTTP, HTTPS, FTP, and other endpoints for my VM.
I have searched the web and this site for hours and still no answer - like lots of other folks it seems.
Details:
I have a website on an Azure Virtual Machine (Server 2008). The website is a copy of our production website hosted on our local server. The website has a WCF service used by a windows desktop client. Everything woks on our local server.
Everything on the Azure server works except access to the service. My registered domain name points to the Azure Server public IP address so accessing website hosted on the Azure machine works.
Example: http://www.mydomainname.com brings up my ASP.NET website. It works as expected including the https binding.
The service seems to be visible to the outside world.
Example http://www.mydomainname.com/Registrations.svc?wsdl brings up the details of the service.
Also, if I put a copy of the client code on the VM and a local host version of the website on the VM (using VS Express for web debug) and change the url in my client to point to the local host version of the service - that all works
I have not changed any firewall settings as of yet because I did not need to do so in our onsite server (or even on an ISP webserver).
Here is the service info:
<system.serviceModel>
<services>
<service name="RegistrationsService" behaviorConfiguration="RegistrationsServiceBehavior">
<endpoint address="" binding="wsHttpBinding" contract="IRegistrations"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="RegistrationsServiceBehavior">
<serviceMetadata httpGetEnabled="true"/>
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true"/>
</system.serviceModel>
Can someone tell me what I may be missing.
Do I need to set up another endpoint for my VM in Azure Portal so WCF will work: Name=AnyName? Protocol= "TCP; public port = ? Private Port= ?
After the above, what ports do I enable in server firewall (the public port or the private port)
Anything else different between an Azure Virtual Machine and other Virtual machines (like our onsite servers or ISP web servers)
Are there any settings I may have missed in IIS or other places. I have everything set just like in our local server where the website and services work.
Any help would be very much appreciated
Dennis
I'm working on a WCF service that is to be consumed by a client that is not developed by me and also it's not .NET (possibly Java).
In any case, the service should support mutual SSL authentication, where both the service and the client authenticate with certificates X.509 certs at the transport layer. The certificates have been exchanged between parties at a prior moment.
My problem is that I cannot seem to get the right WCF configuration such that client certificate authentication works correctly. What I expect is that, as part of the TLS handshake, the server also includes a Certificate Request, as seen below:
Following this, the client should answer with a `Certificate Verify' among other things:
The (latest) service configuration is this one. I'm using a custom binding, with authentication mode set to MutualSslNegotiated.
<bindings>
<customBinding>
<binding name="CarShareSecureHttpBindingCustom">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="MutualSslNegotiated"/>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
</bindings>
...
<serviceBehaviors>
<behavior name="ServiceBehavior">
<serviceMetadata httpGetEnabled="false" httpsGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" httpHelpPageEnabled="false" />
<serviceCredentials>
<serviceCertificate findValue="..." storeLocation="LocalMachine" x509FindType="FindByIssuerName" storeName="My" />
<clientCertificate>
<certificate findValue="..." storeName="My" storeLocation="LocalMachine" x509FindType="FindByIssuerName"/>
</clientCertificate>
</serviceCredentials>
</behavior>
</serviceBehaviors>
The Server Hello part of the handshake looks like this for all service configurations I have tried, with no CertificateRequest.
Other things I should mention:
The service is self hosted and listening on a non-default port (not 443). The server SSL certificate has been bound to this port.
I have also tried a basicHttpBinding and a wsHttpBidning with security mode set to Transport and client authentication set to Certificate, with no results (same results actually).
Any ideas would be appreciated.
OK, after a few more tries I figured it out. Posting this in case others run into the same issue.
I should continue by mentioning that this behavior really needs to be mentioned somewhere on MSDN, in a location that is really visible for anyone looking for WCF security information and not buried deep in some tool's documentation.
The platforms where I've been able to reproduce and fix this: Windows 8.1 x64 and Windows Server 2008 R2 Standard.
As I mentioned, my issue was that I could not configure WCF security such that the service would require client certificates. A common confusion that I noticed while looking for a solution is that many people believe that the client can send the certificate if it has it, unchallenged. This is, of course, not the case - the server needs to ask for it first and, moreover, specify which CAs are allowed through a CertificateRequest reply.
To summarize, my situation was:
Service is self-hosted.
Service runs on HTTPS, on a non standard port (not 443 but 9000).
This meant that I had to create an SSL certificate binding for port 9000 by using netsh.exe http add sslcert. Well, the binding had been created but there was a catch. I only found the issue after running netsh http show sslcert just to check on my binding:
IP:port : 0.0.0.0:9000
Certificate Hash : ...
Application ID : ...
Certificate Store Name : MY
Verify Client Certificate Revocation : Enabled
Verify Revocation Using Cached Client Certificate Only : Disabled
Usage Check : Enabled
Revocation Freshness Time : 0
URL Retrieval Timeout : 0
Ctl Identifier : (null)
Ctl Store Name : (null)
DS Mapper Usage : Disabled
-->Negotiate Client Certificate : Disabled
The culprit was the last property of the binding, "Negotiate Client Certificate", documented here. Apparently, by default, this property is disabled. You need to enable it explicitly while creating the binding.
Recreating binding with the statement below solved the issue:
netsh.exe http add sslcert ipport=0.0.0.0:9000 certhash=... appid=... certstorename=MY verifyclientcertrevocation=Enable VerifyRevocationWithCachedClientCertOnly=Disable UsageCheck=Enable clientcertnegotiation=Enable
Prior to checking the bindings I tried hosting a simple WCF service in IIS and enable client certificate authentication from there. It was very curious to see that although there was no CertificateRequest issued by IIS, it still failed with a 403.7. Even IIS didn't create the binding with the appropriate parameters.
Anyway, now it works and this is how you can fix it.
Not to forget, the service configuration changed as well (the binding security) in order to allow certificate negotiation:
<customBinding>
<binding name="CustomHttpBindingCustom" receiveTimeout="01:00:00">
<textMessageEncoding messageVersion="Soap11" />
<security authenticationMode="SecureConversation" requireSecurityContextCancellation="true">
<secureConversationBootstrap allowInsecureTransport="false" authenticationMode="MutualSslNegotiated" requireSecurityContextCancellation="true"></secureConversationBootstrap>
</security>
<httpsTransport requireClientCertificate="true" />
</binding>
</customBinding>
I had the same issue when my bosses were questioning why was our IIS hosted WCF service which implemented "2 way SSL" (mutual certificate authentication) not observed to be sending "Certificate Request" in the TLS handshake. After some investigation, we finally found that the certificate port binding configuration for Negotiate Client Certificate is disabled.
Get the current binding information by running the below.
netsh http show sslcert
Get the certificate hash and the application GUID from the first record (or the relevant SSL port), then run the following netsh command using an administrator console on the IIS server.
netsh http add sslcert ipport=0.0.0.0:443 certhash=xxxx appid={xxxxx} clientcertnegotiation=enable
Note that if an existing binding already exists for the IIS address and port, the following error will be reported.
SSL Certificate add failed, Error: 183 Cannot create a file when that file already exists.
Run the delete command to remove the existing binding before retrying to add it back again.
netsh http delete sslcert ipport=0.0.0.0:443
After the reconfiguration, the observed Wireshark TLS handshake became as expected. However, in my opinion, this setting doesn't matter in the end as the client certification is used for authentication whether during the initial handshake or afterwards within the encrypted exchange and 2 way SSL is achieved.
I have a Windows forms app which uses WCF services. Our application sends messages using one of our WCF services to specific users running our client, so our callback “http:” string is dynamically constructed each time a message is sent to a user. It includes the server IP address and port (126.221.97.105:701) onto which the current user is logged, the user’s id (56281), and the client GUID (7392d27a-e4a0-42e2-89a3-adc332e28934). So, a typical callback “http:” string looks like this:
http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
We have an http namespace (http://+:701/) on our client and the group “Everyone” is tied to this namespace with all of the access permissions checked (GenericAll, GenericExecute, GenericRead, and GenericWrite). We use “http namespace” to create our namespaces.
Our application has been in production (on Windows Server 2003) for a few years and everything is working fine.
We have recently converted our application to run in the Windows 2008 server environment. The “Target Framework” in each of our projects is set to the “.NET Framework 4.0”. Our application works fine on my Windows 7 developer workstation. That is, I am able to receive messages from our WCF service, but when I place our application onto our Windows 2008 server and I attempt to run the application, I receive the following error message:
"There was no endpoint listening at http://xxx.xxx.xx.xxx:701/CmesCns/CALLBACK/56281/7392d27a-e4a0-42e2-89a3-adc332e28934
that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.”
The http namespace (http://+:701/) exists on my developer workstation and on my Windows 2008 server. The group “Everyone” is tied the namespace on my Windows 7 box and on my Windows 2008 server, and all of the access permissions are checked (GenericAll, GenericExecute, GenericRead, and GenericWrite).
We have been searching the web for an answer but have not discovered anything. Would anybody have any ideas on why this would work on our Windows 7 workstations, but not on our Windows 2008 servers?
Any help is greatly appreciated!
Kevin
When you host a WCF service in IIS you don't specify an absolute url in the address. You should use a relative url to the .svc file. The base url will be determined by the web site where it is hosted.
<service name="WebService.Receptor">
<endpoint
address="/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
and on the client, depending on how your IIS is configured you should obviously specify the full address:
<client>
<endpoint
name="Receptor"
address="http://MyServer:8000/WS.svc"
binding="wsHttpBinding"
contract="IMyContract"
/>
This assumes that you have configured a site in IIS that listens on the 8000 port and that you have hosted your WCF application inside this site.
if it does not help please follow these links, hope it would be useful.
Stack overflow link
Multiple Endpoint
Typically, this error is because there is no endpoint on the server that matches what the client is requesting (the address, the service, or the authentication is different).
However, in my case, I had the exact same error, and it was not due to any of these things.
When I enabled the tracing on IIS and reviewed the svclog trace with SvcTraceViewer.exe (included in Visual Studio), the actual internal error was "Maximum request length exceeded."
My client was uploading an image via the service. And I guess the image was too big.
To enable tracing I added this to the configuration section:
<system.diagnostics>
<sources>
<source name="System.ServiceModel"
switchValue="All"
propagateActivity="true">
<listeners>
<add name="traceListener"
type="System.Diagnostics.XmlWriterTraceListener"
initializeData= "c:\log\Traces.svclog" />
</listeners>
</source>
</sources>
To solve the error, I increased the message request length in the web config and the error went away.
To do this, in the system.websection in the web.config I added the line:
<httpRuntime maxRequestLength="32768" />
Then I added this section inside the configuration section
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="32000000" />
</requestFiltering>
</security>
</system.webServer>
So I recommend you enable tracing and then review the trace for the exact error.
I am getting an error while accessing the core service on SDL Tridion 2011 SP1. When I am trying to browse /webservices/CoreService2011.svc from IIS server, it shows the following error:
This collection already contains an address with scheme http.
There can be at most one address per scheme in this collection. If your service is being hosted in IIS you can fix the problem by setting 'system.serviceModel/serviceHostingEnvironment/multipleSiteBindingsEnabled' to true or specifying 'system.serviceModel/serviceHostingEnvironment/baseAddressPrefixFilters'.
Parameter name: item
Can any one help, how it can be rectified.
I believe you have multiple hostnames setup for your Tridion CME. Or at least you are trying to connect to your Content Manager (in this case with Core Service) using multiple hostnames.
Can you try the following:
connect using localhost (obviously when you are local on the server) E.g. http://localhost/webservices/CoreService2011.svc
If above doesn't work, try looking up what host name is registered in IIS for your SDL Tridion 2011 website (in IIS 7, Right click the website, then choose Edit Bindings...). Try connect to the Core Service using the hostname defined in the website bindings
If above still doesn't solve it, try editing your web.config under "Tridion_Home\webservices" and add the following node under configuration / system.ServiceModel
Node:
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true">
<!-- The attribute "multipleSiteBindingsEnabled" was introduced in .net 4 and removes the need of http module: Tridion.Web.ServiceModel.HttpSvcPortFunneler -->
<!-- For https protocol and/or multiport configuration, uncomment this.
There should be a <add /> entry for each unique combination of protocol and hostname that is configured in IIS Bindings.
<baseAddressPrefixFilters>
<add prefix="http://hostname:portnumber"/>
<add prefix="https://hostname"/>
</baseAddressPrefixFilters>
-->
</serviceHostingEnvironment>
TL;DR version is at the bottom.
I have constructed three WCF web services -- one that's using .NET 4 and two that's using .NET 3.5 -- that is consumed by an Android client. The Android client performs the calls using ksoap2-android. When the services were complete and the client could make all the calls and get all the data from the services, we decided to activate HTTPS communication for the web services. They are hosted on a server running IIS.
I'm not alone on this task. I work full-time with it, mainly the Android client. I have two coworkers, both of which have a lot of other responsibilities. The first is mostly involved in the services and the second is mostly involved in the server.
I've read a lot of guides, blogs and articles on the Internet on how to enable HTTPS for a WCF web service, but still I haven't been able to completely resolve this. For the Android client to be able to consume the client, we are limited to using the basicHttpBinding, since the wsHttpBinding contains some security details that are not supported by Android, or something. I'm not sure, but I read it some forum somewhere. If I'm wrong, I'd happily be corrected!
Okay, so I'll give a short account of what I've done so far:
I've enabled transport security, this is how the binding(s) looks:
<bindings>
<basicHttpBinding>
<binding name="basicHttp" closeTimeout="00:10:00" receiveTimeout="00:10:00" sendTimeout="00:10:00">
<security mode="Transport">
<transport clientCredentialType="None" />
</security>
</binding>
</basicHttpBinding>
</bindings>
I've enabled meta data publishing over HTTPS using this line of code:
<serviceMetadata httpsGetEnabled="true" />
and this:
<endpoint address="" binding="mexHttpsBinding" contract="IMetadataExchange" />
Also, my second coworker has installed a trusted certificate (a real certificate from a CA) on the IIS server and added a https binding on the server.
Okay, so far, so good. Now we could connect to the services in the browser.
When we had done this it was possible to visit the service in the browser in a secure, encrypted, manner.
The problem is that it isn't possible to make a call to the service, neither in Android nor WCF Test Client. If I call the service on the https address, I get a 404 in response. WCF Test Client returns this:
There was no endpoint listening at https://[my service address] that could accept the message. This is often caused by an incorrect address or SOAP action.
To be able to debug this, I'm using Wireshark to intercept the messages and see what really happens. I've found out that after the set up procedures (handshake, establishing trust etc.) the client sends the header and get a 101 Continue in response, after which it POSTs the body. This should be normal behavior. But then the service returns 404 Not Found. Wireshark says that the full request URI is the http address. I've configured the server to use the https address, so why does it make a call to the http address?
I've tried setting the address and listenUri attribute of the endpoint to https and http respectively and the other way around. If I do that, the server answers the request with 405 Method Not Allowed.
Is there any way to solve this? What am I missing?
What am I missing?
TL;DR version below
I'm hosting three WCF SOAP web services with IIS, one using .NET 4 and the others using .NET 3.5. I'm trying to make a call from the WCF Test Client over HTTPS. I've enabled transport security, meta data publishing over HTTPS, installed a trusted certificate and added a https binding on the server.
When I try to make a call from WCF Test Client it says that there was no endpoint listening at the address. Wireshark tells me it makes the call to the http version of the service (i.e. "http://[my address]" instead of "https://[my address]"), although it is configured to call the https address. The service returns 404 Not Found. If I set the address of the service to https and listenUri to http, I get 405 Method Not Allowed. If I do it the other way around it says that it cannot be activated. What am I missing?
I solved this by removing the endpoint and using the <protocolMapping> tag, like this:
<protocolMapping>
<add scheme="https" binding="basicHttpBinding" bindingConfiguration="basicHttps" />
</protocolMapping>