SSL Certificate add failed when binding to port

Question

I created a WebService using WCF. I'm doing self hosting and I want to enable HTTPS. From my understanding for this to happen, I need to create a certificate and bind to the port that I want to use.

Here are the steps that I've done to handle this:

1. Created a Certificate on my local machine to act as the Root Certificate Authority
   • makecert -n "CN=My Root Certificate Authority" -r -sv RootCATest.pvk RootCATest.cer
2. Opened MMC.exe and imported the saved .cer file into the "Trusted Root Certificate\Certificates\ folder
   • makecert -sk MyKeyName -iv RootCATest.pvk -n "CN=MyMachineName" -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer

3. Created a temporary service certificate from the signed Root Certificate Authority

   • makecert -sk MyKeyName -iv RootCATest.pvk -n "CN=MyMachineName" -ic RootCATest.cer -sr localmachine -ss my -sky exchange -pe MyMachineName.cer

4. Tried to Bind the Certificate to the Port number (443 in this case)

   • netsh http add sslcert ipport=0.0.0.0:443 certhash=2c5ba85bcbca412a74fece02878a44b285c63981 appid={646937c0-1042-4e81-a3b6-47d678d68ba9}

The result from step 4 is the following error:

SSL Certificate add failed, Error 1312

A specified logon session does not exist. It may already have been terminated.

Does anyone have a clue why I might be getting this error?

Answer 1

SSL Certificate add failed, Error 1312

A specified logon session does not exist. It may already have been terminated.

I used to have the exact same problem and spent a couple days trying to figure out what the reason was.

To make the long story short: the problem is that you have installed the certificate on the winrm server that does not have PRIVATE KEY.

I have checked this several times. You have to delete your certificate and rebuild it by using makecert for instance, as it is described perfectly here: http://blogs.technet.com/b/jhoward/archive/2005/02/02/365323.aspx

You can easily check if your certificate has private a key as so: mmc - certificates - local machine - personal. Look at the icon of the certificate - it MUST have key sign on the icon.

Answer 2

Just to throw yet another answer into the ring, this is the problem I had:

Although I imported my certificate into the (Local Computer)\... certificate store, I had imported it into the Trusted Root Certification Authorities section. I needed to import it into the Personal section, otherwise this error occurred.

Answer 3

If:

1. you didn't have IIS on your machine (working with self-hosted WCF let's say), and
2. you made your cert request on another machine using IIS Manager (because you didn't understand that the private key comes from ciphers embedded in the cert request - and later the issued .pb7)

then:

1. just go install the .pb7 on the IIS machine you used to make the cert request (local machine/personal/certificates - using mmc);
2. export the cert from that machine, including its private key (assign password); and
3. install it using mmc on the WCF server (local machine/personal/certificates - using mmc).

Then, netsh will let you bind to port 443. No more 1312 errors.

Answer 4

If anyone else runs into this problem and the answers in here do not clearly answer it, the underlying core problem is the private key needs to be imported. If you do not mark the certificate as exportable when you import it, the private key is not imported and you cannot bind it. If you delete it and re-import it and mark it as exportable, then it will work.

It also needs to be the local machine store as others have pointed out.

Answer 5

I had exact same problem eventhough my .pfx file had private key. Adding of certificate with MMC console was successful, but adding programatically using .Net X509Store.Add(X509Certificate2) method failed every time with error 1312. Certificate even had a key sign on the icon.
After several days finaly decided to make new certificate using makecert.exe as suggested in posts here. After that everything was fine. Key appeared in %ProgramData%\Microsoft\Crypto\RSA\MachineKeys. For some reason my earlier pfx file was not compatible.

In my experience, as long as your key in not appearing in %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\, binding with 'netsh http add sslcert ....' will fail.

Answer 6

I had been dealing with this issue and I'm using a self-hosted WCF service. I just made the breakthrough:

I had a certificate in the personnel folder for the Machine store. It expired and my manager issued a new one. The new one failed for me with this error. I tried a lot of stuff from Google but in the end, resolved the issue using a completely different solution.

I installed both certificates- the expired one and the newer one. Then I used this command to get a list of them:

certutil -store My

I get this output (info is fake and other certificate are not listed):

================ Certificate 1 ================
Serial Number: 6d
Issuer: E=[e-mail], CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
 NotBefore: 03-Jan-2013 3:33 PM
 NotAfter: 03-Mar-2013 3:33 PM
Subject: E=[e-mail], CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 98 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
  Key Container = {E5BC0912-7808-4B89-B457-31946DE5990E}
  Unique container name: dfedfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
  Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed

================ Certificate 2 ================
Serial Number: 6d
Issuer: E=[e-mail], CN=VoiceTrust Server CA, OU=VoiceTrust Oper
ations, O=VoiceTrust
 NotBefore: 03-Nov-2013 3:33 PM
 NotAfter: 03-Dec-2013 3:33 PM
Subject: E=[e-mail], CN=hornet.voicetrust.com, OU=Software Develop
ment, O=VoiceTrust eServices MENA FZ LLC, L=Dubai, C=AE
Non-root Certificate
Cert Hash(sha1): 30 5f a0 d3 11 6a 4b 64 3b db 0a a4 11 66 fc 08 28 74 7e 53
  Key Container = {E5BC0912-7808-4B89-B457-31946DE5960E}
  *Unique container name:* 55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b6
4-30f0d6589239
  Provider = Microsoft Enhanced Cryptographic Provider v1.0
Private key is NOT exportable
Encryption test passed

Now, everything seems OK but certificate 1 is expired and works if I try to bind it to a port whereas Certificate 2 fails with Error 1312.

The key difference that baffled me was the Unique container name property. It should be representing a physical key file on the hard drive in the %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\

For Certificate 1, the file was there but for Certificate 2, there was no such file. After searching I found the file against Certificate 2 in the sub folder of %AppData%\Microsoft\Crypto\ folder. That's user specific keys not Machine level keys. It's amazing that the certificate is being imported into Computer store yet it always keeps the container key of User's store.

I deleted the '55edfcc149408fb990a3bacd6d31126b_3277b2c9-9894-46d0-9b64-30f0d6589239' file under the AppData folder and ran the repair command for my certificate 2 on the store:

certutil -repairstore My 2

This time, the Unique container name was reflecting a file in the proper folder under '%ProgramData%\Microsoft\Crypto\' and everything started working.

Hope this is helpful to someone.