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

[gfody]

I started getting this error message, these scripts were working before. same symptoms as #157 but I'm using 4.25.1

$cert = New-PACertificate 'mydomain' -AcceptTOS -Contact 'mycontact' -Plugin Route53 -PluginArgs @{R53UseIAMRole=$true} -Verbose -Force -AlwaysNewKey -Install
>
VERBOSE: Updating directory info from https://acme-v02.api.letsencrypt.org/directory
VERBOSE: Using ACME Server https://acme-v02.api.letsencrypt.org/directory
...
VERBOSE: Finalizing the order.
VERBOSE: Creating new certificate request with key length 2048.
VERBOSE: Creating new private key for the certificate request.
VERBOSE: Downloading signed certificate
VERBOSE: Updating cert expiration and renewal window
VERBOSE: Successfully created certificate.
VERBOSE: Importing CN=mydomain certificate to LocalMachine\My.
VERBOSE: Chain cert 'CN=R10, O=Let's Encrypt, C=US' with thumbprint 00ABEFD055F9A9C784FFDEABD1DCDD8FED741436 already exists in LocalMachine\CA store.

when I try to bind it to a port I get the error in the title

netsh http add sslcert ipport=0.0.0.0:6516 certhash=($cert.Thumbprint) appid='{20835649-704d-4b8d-8021-46ad962ecb83}'

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

I've tried removing and re-installing it but it keeps giving the same error. I can compare the certs in certlm the one that's not working complains if I goto "All Tasks -> Manage Private Keys..." it says "No keys found for certificate!" though if I view it it says "You have a private key that corresponds to this certificate."

The only visible difference in certlm is that the broken one has friendly name matching the domain name.

[rmbolger]

Hey @gfody, thanks for reaching out. Unfortunately, I don't have any insight as to why this would suddenly break for you. The code for importing the certs hasn't changed in 3 years. The only Let's Encrypt related thing that has changed recently was the expiration of the old DST cross-signed root. But it doesn't seem like that should affect Windows' ability to access the private key for your cert. LE certs haven't been chaining to that root in quite some time. You could also rule this out by temporarily switching to another ACME CA.
https://community.letsencrypt.org/t/shortening-the-lets-encrypt-chain-of-trust/201580

Based on the previous issue and some web searching surrounding the error message, there doesn't seem to be any one magic reason this happens. It might be related to the .NET version PowerShell is running on. So differences between running on PowerShell 7+ or 5.1 might matter. It might also be related to a recent hotfix from Microsoft at the OS level. Here's a thread with various potential workarounds/solutions.
https://stackoverflow.com/questions/13076915/ssl-certificate-add-failed-when-binding-to-port

If you can give me some details about your specific environment (OS version, PowerShell version, .NET Framework version if on PowerShell 5.1), I can see if I can try to reproduce it on my end.

[gfody]

the netsh command succeeded after re-importing the pfx via certlm.msc

If you can give me some details about your specific environment (OS version, PowerShell version, .NET Framework version if on PowerShell 5.1), I can see if I can try to reproduce it on my end.

appreciate it!
PSVersion 7.4.5
Windows Server 2022 (21H2 Build 20348.2402)
.NET 4.8.1 (533325)

here's the output of dotnet --info in case it's relevant

dotnet --info
.NET SDK (reflecting any global.json):
 Version:   6.0.425
 Commit:    fcce060d9f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.20348
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\6.0.425\

Host:
  Version:      8.0.4
  Architecture: x64
  Commit:       2d7eea2529

.NET SDKs installed:
  6.0.425 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.29 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 6.0.33 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 8.0.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

Other architectures found:
  None

Environment variables:
  Not set

global.json file:
  Not found

[billacuda]

Hi, I'm running into this same issue on Server 2016, PowerShell 7.5. My workaround was to use openssl to build a new pfx file from fullchain.cer and cert.key. Windows certificate store said the cert installed by Install-PACertificate had a private key associated with it, but when you select Manage private keys there weren't any assigned. Very odd! I haven't run into this issue on Server 2019 or Server 2022 yet so I plan on upgrading this 2016 server sooner than later.

[webprofusion-chrisc]

This is often related to private key permissions, or it can be an issue where a private key is accidentally being created as "ephemeral" instead of persisting to the machine key set.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders

As an aside if you run a task as Local System there is/was also a windows bug where the PFX needed to be stored twice for it to stick.

[billacuda]

This is often related to private key permissions, or it can be an issue where a private key is accidentally being created as "ephemeral" instead of persisting to the machine key set.

https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/default-permissions-machinekeys-folders

As an aside if you run a task as Local System there is/was also a windows bug where the PFX needed to be stored twice for it to stick.

As a test I requested a certificate for a different hostname on a 2022 machine, then tried to import the fullchain.pfx file on the 2016 machine and got the parameter incorrect error and the private key was missing, even though when you view the certificate in the local machine store it says a matching key is installed. I then used openssl to combine the fullchain.cer and cert.key files on the 2022 machine, then imported that pfx file into the server 2016 local machine store and that worked perfectly and the private key showed up and I could apply it to IIS sites.

I can replicate this issue on every 2016 machine we have at this point, but we have a workaround until we can get them upgraded to 2019 or later. Maybe it's something to do with how Sectigo is sending the certificates back to us that isn't immediately compatible with 2016 anymore?

[rmbolger]

I think what @webprofusion-chrisc was saying is that you shouldn't need the step where you use openssl. If you just delete the imported copy that's not working and re-import using the same fullchain.pfx, it should work when importing the second time.

[billacuda]

Yep, tried that multiple times on several machines and ran into the same issue with fullchain.pfx as well. The same pfx file works on on 2019 and 2022 so I'm at a bit of a loss.

[webprofusion-chrisc]

Oh wait, @rmbolger does Posh-ACME use modern PFX algs by default? For Certify The Web we've previously found that doesn't work for older windows or instances that have been in-placed upgraded.

[rmbolger]

Not by default. You'd need to opt-in via the -UseModernPfxEncryption switch on an order. It won't become default until the next major version.

Part of me really wants to spin up a 2016 box and get a reliable repro for this that I can hack on. The other part doesn't want to bother with an OS that has been out of mainstream support for 3 years. But there are other folks who have seen similar problems on more recent OS versions too. So it's possible that repro'ing on 2016 would potentially lead to fixes for other versions.

[billacuda]

Aha, thank you everyone. After your recent comments I went back through my entire script and found I was setting UseModernPFXEncryption to $true in my default certificate parameters. I added a check so if the server version is 2016 it sets that to $false and everything is working now.

[rmbolger]

Hah, nice! At least one mystery solved.

Hey @gfody, I know you're not running Server 2016. But can you double check whether your order has the ModernPfxEncryption flag enabled?

(Get-PAOrder).UseModernPfxEncryption