IIS 7 Error "A specified logon session does not exist. It may already have been terminated." when using https

Question

I am trying to create Client Certificates Authentication for my asp.net Website.

In order to create client certificates, I need to create a Certificate Authority first:

makecert.exe -r -n “CN=My Personal CA” -pe -sv MyPersonalCA.pvk -a sha1 -len 2048 -b 01/01/2013 -e 01/01/2023 -cy authority MyPersonalCA.cer

Then, I have to import it to IIS 7, but since it accepts the .pfx format, i convert it first

pvk2pfx.exe -pvk MyPersonalCA.pvk -spc MyPersonalCA.cer -pfx MyPersonalCA.pfx

After importing MyPersonalCA.pfx, I try to add the https site binding to my Web Site and choose the above as SSL Certificate, but I get the following error:

Any suggestions?

Solution 1

This must be some kind of IIS bug, but I found the solution.

1- Export MyPersonalCA.pfx from IIS.

2- Convert it to .pem:

openssl pkcs12 -in MyPersonalCA.pfx -out MyPersonalCA.pem -nodes

3- Convert it back to .pfx:

openssl pkcs12 -export -in MyPersonalCA.pem -inkey MyPersonalCA.pem -out MyPersonalCA.pfx

4- Import it back to IIS.

Solution 2

I ran across this same issue, but fixed it a different way. I believe the account I was using changed from the time I initially attempted to set up the certificate to the time where I returned to finish the work, thus creating the issue. What the issue is, I don't know, but I suspect it has to do with some sort of hash from the current user and that is inconsistent in some scenarios as the user is modified or recreated, etc.

To fix it, I ripped out of both IIS and the Certificates snap-in (for Current User and Local Computer) all references of the certificate in question:

Next, I imported the *.pfx file into the certs snap-in in MMC, placing it in the Local Computer\Personal node:

1. Right-click the Certificates node under Personal (under Local Computer as the root)
2. All Tasks -> Import
3. Go through the Wizard to import your *.pfx

From that point, I was able to return to IIS and find it in the Server Certificates. Finally, I went to my site, edited the bindings and selected the correct certificate. It worked because the user was consistent throughout the process.

To the point mentioned in another answer, you shouldn't have to resort to marking it as exportable as that's a major security issue. You're effectively allowing anyone who can get to the box with a similar set of permissions to take your cert with them and import it anywhere else. Obviously that's not optimal.

Solution 3

Security warning: what the checkbox really means is that the certificate can be read by users that shouldn't be able to read it. Such as the user running the IIS worker process. In production use the other answer instead.

Happened to me too, and was fixed by ensuring that "Allow this certificate to be exported" is checked when you import it:

                                           

(thanks to this post!)

Solution 4

We had the same issue due to incorrectly importing the certificate into the Current User Personal certificate store. Removing it from the Current User Personal store and importing it into the Local Machine Personal certificate store solved the problem.

Solution 5

Nobody probably cares about this anymore, but I just faced this issue with my IIS 7 website binding. The way I fixed it was going to the Certificate Authority and finding the certificate issued to the server with the issue. I verified the user account that requested the certificate. I Then logged into the IIS server using RDP with that account. I was able to rebind the https protocol using that account only. No exports, reissuing, or extension changing hacks were needed.

View more solutions

Comments

[Adnane ARHARBI]

I ve some problem

[lanoxx]

Isn't that a security risk?

[Jonathan Oliver]

I first had to remove the certificate under the MMC snap-in certificate store "Certificates (Local Computer)/Personal" and the in the same store, I right clicked and selected import and then imported the certificate marking it as exportable.

[aboy021]

@lanoxx you still need the password in order to export the certificate, so it's not totally without security.

[lanoxx]

@aboy021: No you don't. The password which you enter will be used to encrypt the certificate again, but you can choose any password and it does not need to match the original one that was used to import the certificate.

[aboy021]

@lanoxx ouch, thanks for clarifying that. Now I just need a way to get this to work without "Allow this certificate to be exported" checked.

[WhiteKnight]

You also can't grant the IIS Application Pool access to the private key without marking the certificate as exportable

[Steven De Kock]

This is a major security risk. Anyone with administrative access can export your private key. Use Mike L's answer instead.

[Steven De Kock]

@romkyns You're right, but you'd need third party tools to do it. When the key is exportable, non-administrative users with read permissions (can be managed with MMC) can also export the private key. In this case it would include the IIS worker process ...

[MarioVW]

In my case the problem was that I imported a *.cer file into the certificate store. Make sure to import a *.pfx file into the certificate store.

[Katstevens]

It seems as though following these steps (rather than importing directly into Server Certificates) brings in the intermediary certs as well, which seems significant.

[pim]

All I can say is thanks @Mike L -- this is literally the only thing that worked for me.

[OnceUponATimeInTheWest]

I would say this is generally the right answer because it is such an easy mistake to make. If you start the certificate manager using Certmgr.msc you get the personal store rather than the computer store. That means the logons are different. Instead you have to use mmc and then add the snap-in which allows you to select computer store.

[Jonathan Williams]

I used this solution. However, GoDaddy only gave us a .crt file for our new certificate, so to extract the private key from the previous certificate (using openssl) and then create a .pfx from this (and the .crt) and import that.

[ErikusMaximus]

My issue was that IIS wasn't importing the full certificate chain (i.e. parent cert), but only the child cert.

[ryanulit]

Adding another possible solution. For me it was because I imported the certificate within IIS instead of from the Windows Certificate Manager.

[Etienne]

this answer was the easiest solution for me, still not sure what was wrong though.

[Umang]

Any explanation to why it fixed would much more helpful

[blizz]

I could kiss you!

[Humberto Garza]

Thanks! This was 1000 times simpler than what I was doing with PowerShell!