Does netsh add sslcert with a http url still enable ssl? - wcf

When hosting a WCF service in a windows service, we can use netsh http add urlacl url=https://+:1234/xService user=DOMAIN\USER
Then to add SSL we could do:
netsh http add sslcert ipport=0.0.0.0:1234 certhash="xxxxx" appid="{xxxxx}".
In the example code here https://msdn.microsoft.com/en-us/library/ms733791(v=vs.110).aspx they seem to use a http address.
Does this make any difference? If you run netsh http add sslcert on a port reserved with a http:// address will it still be secured by the certificate, or does it have to be a https address?

It needs to use https and your service should also serve https://...

Related

netsh http add urlacl fail - parameter is incorrect

I'm trying to register wcf net tcp port sharing, for a process to listen on this port (currently the client machine can't even ping this port eventhough the process is up so I read this command is needed):
netsh http add urlacl user=domain\svcUser url=net.tcp://+:8092/Service1
getting Url reservation failed, Error 87. The parameter is incorrect.
Also tried changing the user, the port, removing the Service1, adding a trailing /. Is there anything else that should be done?
Remark: The following command does succeed (but does not help): netsh http add urlacl user=domain\svcUser url=http://+:8092/Service1
This post shows the usage of netsh in this case
This post deals with error 87 but did not solve in my case
You mean the command succeed but it didn't work. This is not normal.
Maybe you can try this:
netsh http add urlacl url=http://+:8092 user=domain\svcUser

Cannot unbind a certificate from a port (Windows 7)

On Friday I successfully bound my certificate to port 443 using netsh.
Today I need to change the port, so I tried to 'unbind' it with netsh:
netsh delete sslcert ipport=0.0.0.0:443
The result is an error message
The following command was not found: delete sslcert
ipport=0.0.0.0:443.
Confusingly the command is exactly as specified in the Microsoft documentation for netsh.
How do I remove a port binding so that I can rebind the certificate to another port?
Try this one
netsh http delete sslcert ipport=0.0.0.0:443
You were missing the http parameter.

Running Fiddler as a Reverse Proxy for HTTPS server

I have the following situation: 2 hosts, one is a client and the other an HTTPS server.
Client (:<brwsr-port>) <=============> Web server (:443)
I installed Fiddler on the server so that I now have Fiddler running on my server on port 8888.
The situation i would like to reach is the following:
|Client (:<brwsr-port>)| <===> |Fiddler (:8888) <===> Web server (:443)|
|-Me-------------------| |-Server--------------------------------|
From my computer I want to contact Fiddler which will redirect traffic to the web server. The web server however uses HTTPS.
On The server I set up Fiddler to handle HTTPS sessions and decrypt them. I was asked to install on the server Fiddler's fake CA's certificate and I did it! I also inserted the script suggested by the Fiddler wiki page to redirect HTTPS traffic
// HTTPS redirect -----------------------
FiddlerObject.log("Connect received...");
if (oSession.HTTPMethodIs("CONNECT") && (oSession.PathAndQuery == "<server-addr>:8888")) {
oSession.PathAndQuery = "<server-addr>:443";
}
// --------------------------------------
However when I try https://myserver:8888/index.html I fail!
Failure details
When using Fiddler on the client, I can see that the CONNECT request starts but the session fails because response is HTTP error 502. Looks like no one is listening on port 8888. In fact, If I stop Fiddler on the server I get the same situation: 502 bad gateway.
Please note that when I try https://myserver/index.html and https://myserver:443/index.html everything works!
Question
What am I doing wrong?
Is it possible that...?
I thought that since maybe TLS/SSL works on port 443, I should have Fiddler listen there and move my web server to another port, like 444 (I should probably set on IIS an https binding on port 444 then). Is it correct?
If Fiddler isn't configured as the client's proxy and is instead running as a reverse proxy on the Server, then things get a bit more complicated.
Running Fiddler as a Reverse Proxy for HTTPS
Move your existing HTTPS server to a new port (e.g. 444)
Inside Tools > Fiddler Options > Connections, tick Allow Remote Clients to Connect. Restart Fiddler.
Inside Fiddler's QuickExec box, type !listen 443 ServerName where ServerName is whatever the server's hostname is; for instance, for https://Fuzzle/ you would use fuzzle for the server name.
Inside your OnBeforeRequest method, add:
if ((oSession.HostnameIs("fuzzle")) &&
(oSession.oRequest.pipeClient.LocalPort == 443) )
{
oSession.host = "fuzzle:444";
}
Why do you need to do it this way?
The !listen command instructs Fiddler to create a new endpoint that will perform a HTTPS handshake with the client upon connection; the default proxy endpoint doesn't do that because when a proxy receives a connection for HTTPS traffic it gets a HTTP CONNECT request instead of a handshake.
I just ran into a similar situation where I have VS2013 (IISExpress) running a web application on HTTPS (port 44300) and I wanted to browse the application from a mobile device.
I configured Fiddler to "act as a reverse proxy" and "allow remote clients to connect" but it would only work on port 80 (HTTP).
Following on from EricLaw's suggestion, I changed the listening port from 8888 to 8889 and ran the command "!listen 8889 [host_machine_name]" and bingo I was able to browse my application on HTTPS on port 8889.
Note: I had previously entered the forwarding port number into the registry (as described here) so Fiddler already knew what port to forward the requests on to.

Selfhosting a WCF service over Https

I want to write a WCF service (self-hosted) that should use https.
By searching the web I found a blog article from msdn that tells me
to use the "netsh.exe" command to bind the certificate to the endpoint
by commandline:
http://blogs.msdn.com/b/james_osbornes_blog/archive/2010/12/10/selfhosting-a-wcf-service-over-https.aspx
However, is this still state of the art?
Why not use this:
http://msdn.microsoft.com/de-de/library/system.servicemodel.description.servicecredentials.servicecertificate(v=vs.100).aspx
Or do I miss something?
Thanks for any help.
So I finally found out why I need to use the netsh command:
Check this article:
https://msdn.microsoft.com/en-us/library/ms789011%28v=vs.110%29.aspx
From this article:
If the transport is HTTP (using the WSHttpBinding), SSL over HTTP provides the transport-level security. In that case, you must
configure the computer hosting the service with an SSL certificate
bound to a port, as shown later in this topic. If the transport is
TCP (using the NetTcpBinding), by default the transport-level security
provided is Windows security, or SSL over TCP. When using SSL over
TCP, you must specify the certificate using the SetCertificate method,
as shown later in this topic.
So you can only use the Property for tcp binding.
If you use ssl over http, you need to bind a certificate to a port by netsh command

Servicehost throwing an error, even though added to configuration with netsh

ServiceHost.Open() is throwing this error:
HTTP could not register URL http://+:8001/. Your process does not have
access rights to this namespace (see
http://go.microsoft.com/fwlink/?LinkId=70353 for details).
So I used netsh to add the url. But event though it is added, i'm still getting the error. This is the command I use:
netsh http add urlacl url=http://+:8001/ user=djerryy
djerryy is my computername. When I run netsh http show urlacl i see it was added.
What am I doing wrong?
Thanks in advance.
It looks like you are missing the name of the user account who is running the service. Here's a couple of options:
Local user account:
netsh http add urlacl url=http://+:8001/ user=ComputerName\Username
Domain user account:
netsh http add urlacl url=http://+:8001/ user=DomainName\Username
Built-in NetworkService account:
netsh http add urlacl url=http://+:8001/ user="NT AUTHORITY\NETWORK SERVICE"
I must stress:
netsh http add urlacl url=http://+:8001/ user="NT AUTHORITY\NETWORK SERVICE"
will work only on a system with the English locale!
A better way is to remove that one space and make it:
netsh http add urlacl url=http://+:8001/ user="NT AUTHORITY\NETWORKSERVICE"
Now the command will work on any locale. I spent a good 0,5h battling this today... all because of a single char. ;)
To add even more to this answer: You MUST specify a port number! Spend quite a while trying to authorize a service to bind to a normal HTTP address, it only started working when I explicitly specified:
netsh http add urlacl
url=http://some.example.com:80/extension/
user="NT AUTHORITY\NETWORKSERVICE"