Fixing the IIS Binding Error - A Specified Logon Session Does Not Exist
Kevin TaylorShare
Few Windows errors are worded as unhelpfully as the binding failure stating that a specified logon session does not exist. Nothing about sessions or logons is actually wrong. The message means Internet Information Services (IIS) cannot reach the Private Key behind the SSL Certificate being bound, and every fix below restores that connection.
What Actually Went Wrong
Windows stores the SSL Certificate and its Private Key separately, linked by an internal reference. The link breaks in predictable ways, with the most common being an import performed by double clicking the file, which lands material in the user store rather than the machine store that Internet Information Services (IIS) reads.
Imports restored from backups, moved between servers, or performed under different accounts break the link in the same way, leaving an SSL Certificate that looks perfectly healthy in the list yet fails the moment a binding tries to use it.
Confirming the Diagnosis
Open the Microsoft Management Console (MMC) with the Certificates snap-in targeting the Computer Account, navigate to Personal, and open the SSL Certificate. A healthy entry states at the bottom of the General tab that you have a Private Key corresponding to it.
An entry missing that line, or an entry present only under Current User rather than Local Computer, confirms the broken link and points at the fix.
Repairing the Key Association
When the Private Key exists on the machine but the link is broken, one command rebuilds it. Find the thumbprint on the Details tab of the SSL Certificate, then run the repair from an elevated prompt.
certutil -repairstore my AB12CD34EF56AB12CD34EF56AB12CD34EF56AB12
A completed repair restores the Private Key line in the properties dialog, and the binding that failed moments earlier succeeds immediately, with no restart needed.
Note : A thumbprint pasted from the dialog sometimes carries an invisible leading character that makes certutil report the SSL Certificate as not found. Deleting and retyping the first few characters by hand clears it.
When the repair completes, stop here. When it fails, the next section applies.
Reimporting When Repair Fails
A repair that fails means the Private Key is not on the machine at all, which happens when only the public half was ever imported.
The clean fix is removing the broken entry and importing the original Personal Information Exchange (PFX) file properly, into the Local Computer Personal store, since the PFX file carries the key inside it. Learn About Understanding PFX Files 🔗
Import through the MMC snap-in targeting the Computer Account, or from an elevated prompt with certutil -importpfx, and avoid the double click route entirely, which is what created the problem on most affected servers.
When No PFX File Exists
A server holding only a .crt file and no PFX file has nothing containing the Private Key, and no repair can conjure it. Generate a fresh Certificate Signing Request (CSR) on the server, which creates a new key in the right place, and complete a reissue against it. Learn About Reissuing Your SSL Certificate 🔗
The replacement then completes with certreq -accept, binds cleanly, and the original error never returns. Confirming the pairing before binding is a thirty second check that catches this whole family of problems early. Learn About Verifying a Private Key Matches an SSL Certificate 🔗
