# "A specified logon session does not exist" in IIS: fix

> IIS shows this error (0x80070520) when the certificate's private key is missing or inaccessible. How to check the key, re-import the PFX and rebind.

Source: https://ssl.sh/errors/iis-specified-logon-session-does-not-exist/
Last updated: 2026-11-10

**"A specified logon session does not exist. It may already have been terminated." means Windows could not open the private key of the certificate you tried to bind to an HTTPS site.** It is generic Windows error 1312 (`ERROR_NO_SUCH_LOGON_SESSION`). Usually the key is missing, in the wrong store or inaccessible.

## What you see

In IIS Manager > Site > Bindings > Add or Edit, after selecting the certificate:

```text
A specified logon session does not exist. It may already have been terminated.
(Exception from HRESULT: 0x80070520)
```

`0x80070520` is the HRESULT form of Win32 error 1312 (0x520). With `netsh`:

```text
SSL Certificate add failed, Error: 1312
```

## Common causes, most frequent first

### 1. The certificate has no private key on this server

You imported a `.cer` or `.crt` file, which never contains the key, or you clicked Complete Certificate Request on a server other than the one that generated the CSR. The certificate appears in the store but cannot be used for TLS.

Check from PowerShell:

```powershell
Get-ChildItem Cert:\LocalMachine\My | Format-List Subject, Thumbprint, HasPrivateKey, NotAfter
```

`HasPrivateKey : False` confirms it.

### 2. The certificate and key are in the Current User store

Double-clicking a PFX opens the import wizard with the Current User store preselected. A key imported there belongs to your user profile, and moving only the certificate to Local Computer in the console may leave the key behind, so IIS, which works through system services, cannot open it. Look in `certmgr.msc` (Current User) for a copy of the certificate.

### 3. The system cannot access the private key file

Microsoft's archived IIS support post describes a certificate that worked on IIS 6 but failed on IIS 7 with exactly this error. `certutil` reported that the encryption test failed, and the cause was that the Administrators group had no permission on the private key file in `C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys`. Microsoft documents the default permissions for that folder. Check the key with:

```bash
certutil -verifystore My <thumbprint>
```

Look for "Encryption test passed". A failure points to a missing or unreadable key.

### 4. A broken key association after cloning or restore

Images cloned or restored from backup sometimes carry certificates whose key association no longer resolves. `certutil -repairstore` can rebuild the association when the key exists on the machine:

```bash
certutil -repairstore My <serial-number>
```

## How to fix it

Re-import the certificate together with its private key into the Local Computer store, then rebind.

**1. Get a PFX that contains the private key.** If you only have the certificate, export a PFX from the server that created the CSR, or convert PEM files with the [SSL converter](https://ssl.sh/tools/ssl-converter/). Check that the key belongs to the certificate with the [key matcher](https://ssl.sh/tools/key-matcher/).

**2. Remove the broken copies** from Local Computer > Personal and Current User > Personal (`certlm.msc` and `certmgr.msc`).

**3. Import into Local Computer > Personal:**

```powershell
$pw = Read-Host -AsSecureString
Import-PfxCertificate -FilePath C:\certs\example.com.pfx -CertStoreLocation Cert:\LocalMachine\My -Password $pw
```

Add `-Exportable` only if you must move the certificate later.

**4. Rebind** in IIS Manager, or with netsh using the certificate's thumbprint:

```bash
netsh http add sslcert hostnameport=example.com:443 certhash=<thumbprint> appid={00000000-0000-0000-0000-000000000000} certstorename=MY
```

**5. If the key exists but access fails**, restore the default permissions on the MachineKeys folder as documented by Microsoft rather than granting broad access.

Step-by-step installation on IIS is in [IIS SSL certificate](https://ssl.sh/guides/iis-ssl-certificate/).

## Why the message mentions a logon session

Windows uses one shared table of system error codes. Code 1312 sits in the block of security and account errors, next to codes such as 1326, `ERROR_LOGON_FAILURE` ("The user name or password is incorrect."). IIS displays the standard text for whatever code it gets back while creating the binding, so the wording comes from that table, not from anything about user logons. In this situation read it as "the private key for this certificate cannot be used here". Chasing logon or session problems on the server leads nowhere.

## Renewals: prevent it next time

Most occurrences happen during manual renewals, when someone completes a request on the wrong machine or imports the wrong file. Generate the CSR and complete the request on the same server, or receive a PFX that includes the key. Keep a password-protected PFX backup in a secure place. With certificate lifetimes now capped at 200 days and dropping to 100 days in March 2027, an ACME client such as win-acme that renews and rebinds automatically removes the manual step entirely.

## How to verify the fix

1. `Get-ChildItem Cert:\LocalMachine\My` shows `HasPrivateKey : True` for the certificate.
2. `certutil -verifystore My <thumbprint>` reports that the encryption test passed.
3. The binding saves without an error, and `netsh http show sslcert` lists it with the right hash.
4. Browse to the site and confirm the new certificate with the [SSL checker](https://ssl.sh/tools/ssl-checker/); see [Schannel errors](https://ssl.sh/errors/windows-schannel-errors/) if the handshake still fails.