Httplistener with HTTPS support
There seems to be a lot of confusing, sometimes conflicting, information with regards to making a .NET HTTPListener HTTPS capable. My understanding is as follows:
One's C# code needs an
https
prefix (for example,https://*:8443
) in order for the listener to understand that it needs to service SSL requests at this port.The actual SSL handshake happens under the covers and is handled by
http.sys
(buried somewhere on the Windows machine). The C# code doesn't have to explicitly manage the SSL handshake, because it happens under the covers.One needs to have a "X.509 trusted certificate" on the
httpListener
machine, and somehow that certificate needs to be bound to port 8443 (in this example).
Is my understanding above correct? If not, please educate me.
Regarding X.509 certificates, my understanding is:
- Use
makecert
to create an X.509 certificate. This certificate gets stored in the personal store and needs to get moved over to the Trusted Store (this is where the HTTP listener will look). It seems I can usecertMgr
to perform the move, or I can usemmc
to effect the move. It seems there is more than one X.509 certificate format (DER
,Base64
,pks
, pswd protected,pks
private, etc.)... Is there a preferred format I should use?
Once I get the certificate into the trusted store, I need to bind it to the TCP port. I am on Windows 7: should I be using httpcfg
or netsh
?
I did a bunch of homework and got this working. The steps to add SSL support for an .NET HttpListener are:
-
Update C# application code to include the
https
prefix. Example:String[] prefixes = { "http://*:8089/","https://*:8443/" };
That's it from the code aspect.
-
For the certificate side of things, using the Windows SDK command console or Visual Studio Professional command console
-
Use
makecert.exe
to create a certificate authority. Example:makecert -n "CN=vMargeCA" -r -sv vMargeCA.pvk vMargeCA.cer
-
Use
makecert.exe
to create an SSL certificatemakecert -sk vMargeSignedByCA -iv vMargeCA.pvk -n "CN=vMargeSignedByCA" -ic vMargeCA.cer vMargeSignedByCA.cer -sr localmachine -ss My
Use MMC GUI to install CA in Trusted Authority store
- Use MMC GUI to install an SSL certificate in Personal store
-
Bind certificate to
IP address:port
and application. Example:netsh http add sslcert ipport=0.0.0.0:8443 certhash=585947f104b5bce53239f02d1c6fed06832f47dc appid={df8c8073-5a4b-4810-b469-5975a9c95230}
The certhash is the thumbprint from your SSL certificate. You can find this using mmc. The appid is found in Visual Studio...usually in assembly.cs, look for the GUID value.
-
There may be other ways to accomplish the above, but this worked for me.
Here are the steps, in detail, that I followed to set up a stand-alone server on Windows, using OpenSSL to create the self-signed certificate for a C# HTTPListener
application. It includes plenty of links, in case you want to do further research.
-
Create a stand-alone server in .NET via
HttpListener
:var prefixes = {"http://localhost:8080/app/root", "https://localhost:8443/app/root"}; var listener = new HttpListener(); foreach (string s in prefixes) listener.Prefixes.Add(s); listener.Start();
-
Create self-signed certificate:*
-
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365
, which will prompt you for the value of each of the certificate's fields on the command line. For the common name, type the domain name (e.g.localhost
) -
openssl pkcs12 -inkey bob_key.pem -in bob_cert.cert -export -out bob_pfx.pfx
, so that it can be imported with its key on the target machine.
*For an alternative using
makecert
, see Walter's own answer. -
-
Open Certificate Manager for the Local Machine. When you run
certmgr.msc
, it opens the Certificate Manager for the current user, which is not what we want here. Instead:- From an administrative command prompt on the target machine, run
mmc
- Press Ctrl + M, or Click File > Add/Remove Snap-in
- Choose
Certificates
, and click Add > - In the dialog that appears, Choose
Computer Account
, and click Next - Choose
Local Computer
. Click Finish, then Okay
- From an administrative command prompt on the target machine, run
-
Import the certificate (
pfx
) into the Windows Certificate Store on the target machine- In the
mmc
window previously opened, drill down to Certificates (Local Computer) > Personal - Right-click on
Personal
, then click on All Tasks -> Import... - In the 2nd screen of the dialog that appears, find and import your certificate. You'll have to change the file-type filter to
Personal Information Exchange
orAll Files
in order to find it - On the next screen, enter the password you chose in step 2.1, and pay close attention to the first check box. This determines how securely your certificate is stored, and also how convenient it is to use
- On the last screen, choose
Place all certificates in the following store
. Verify that it saysPersonal
, then click Finish - Repeat the import procedure above for the
Trusted Root Certification Authorities
certificates section.
- In the
-
Create the port associations for your application. On Windows Vista and later, use
netsh
, as I did. (For Windows XP and earlier, usehttpcfg
)-
From the administrative command line, type the following to set up the SSL binding* to your app, and the appropriate port. NB: This command is easy to get wrong, because (in PowerShell) the braces need to be escaped. The following PowerShell command will work:
netsh http add sslcert ipport=0.0.0.0:8443 ` certhash=110000000000003ed9cd0c315bbb6dc1c08da5e6 ` appid=`{00112233-4455-6677-8899-AABBCCDDEEFF`}
For
cmd.exe
, the following should be used instead:netsh http add sslcert ipport=0.0.0.0:8443 certhash=110000000000003ed9cd0c315bbb6dc1c08da5e6 appid={00112233-4455-6677-8899-AABBCCDDEEFF}
- The
ipport
parameter will cause the SSL certificate to bind to the port8443
on every network interface; to bind to a specific interface (only), choose the IP address associated with that network interface. - The
certhash
is simply the certificate thumbprint, with spaces removed - The
appid
is the GUID stored in the Assembly Info of your application. (Sidenote: Thenetsh
mechanism is evidently a COM interface, judging from this question and its answers)
* Microsoft has redirected the SSL Binding link from here to there.
- The
-
Start up your web-server, and you're good to go!