Self-hosting using SSL and WCF - can't bind certificate to port

I have a WCF service that I want to access using SSL. I'm on my developer machine, so I was thinking of self-hosting the service. I've been following Configuring HTTP and HTTPS.

I've created a self-signed certificate which I added t开发者_开发问答o the Trusted Root Certification Authorities. I've created another two certificates signed by the first one, one for the client and the other for the server. I followed Using makecert to create certificates for development.

I can't get past the SSL certificates configuration step. When I'm binding the certificate to the port number using netsh it throws an SSL error:

Certificate add failed, Error: 1312 A specified logon session does not exist. It may already have been terminated.

Does the certificate need some special field or some other thing for this to work?

CA certificate:

makecert -n "CN=TestCA" -cy authority -a sha1 -sv "TestCA.pvk" -r "TEST_CA.cer"

Service certificate:

makecert -n "CN=rneapp.com" -ic "TEST_CA.cer"  -iv "TestCA.pvk" -a sha1 -sky exchange -pe -sv "rneapp.com.pvk" "rneapp.com.cer"

Client certificate:

makecert -n "CN=rneClient" -ic "TEST_CA.cer"  -iv "TestCA.pvk" -a sha1 -sky exchange -pe -sv "rneClient.pvk" "rneClient.cer"

I'm using this command to bind the certificate to the port:

netsh http add sslcert ipport=0.0.0.0:8465 certhash=a853f3b5b48b8a506bdc4212ba2726a3bfea2bb6 appid={2E53B9B0-17AE-4EBC-A1AE-43D53A6FD07D} clientcertnegotiation=enable

---

When I encountered the same issue, moving the certificate from Current User to Local Computer storage helped, so try checking your certificate storage.

Built-in help for netsh http add sslcert also mentions this with regard to certstorename option:

        certstorename           - Store name for the certificate. Defaults
                                  to MY. Certificate must be stored in the
                                  local machine context.

---

I also run into similar error code through different process of creating the self-signed certificate and find the source of my own problem. Using netsh, bind an SSL certificate to a port number is failing

Here is the article I follow to create the self-signed certificate and it is quite complete and thorough.

---

I have exactly the same issue on Windows 7 and Windows Server 2008 R2 but for me it is working the first time I bind the certificate with the port. However if I delete the binding (netsh.exe http delete sslcert ipport=0.0.0.0:9101) and bind again with the same certificate, it fails. If I try another port, it fails. If I create a brand new certificate then I can bind again. But again deleting/binding will fail.

I follow the same rules as this question: Can't register a C# generated selfsigned SSL certificate with netsh (error 1312)

I also tried to install KB981506 http://support.microsoft.com/kb/981506 but it failed to install "The update is not applicable to your computer". Maybe I have it already.

I have a feeling something is not deleted in a right way when the binding is deleted. ProcessMonitor doesn't show any thing weird when I try to bind again.

---

This seems to be a known issue. Check out this Microsoft KB article.

You may also be setting up the certificates incorrectly. Check out this MSDN forum post for how another person was making a similar mistake and getting the 1312 error which was just distracting him from the real problem which was his certificate configuration.

---

I had a similar problem today, and this is how I fixed it. When I have watched certificates installed on my local computer/my in mmc.exe, I have seen that my certificate haven't icon with key.

So when I combine *.cer and *.pvk file to *.pfx with:

pvk2pfx -pvk "private_key.pvk"  -spc "public.cert" -pfx "test.pfx"

And then import *.pfx file with mmc.exe.

Then the next commands will execute with no errors:

netsh http add sslcert...
netsh http delete sslcert...

I have posted this answer to similar Stack Overflow question, Can't register a C# generated selfsigned SSL certificate with netsh (error 1312).