Other things to look out for would be accidentally using an Elliptic Curve private key where you previously used RSA, normally that should be ok but some older version of Windows do have trouble. LE do change some aspect of certificates (CRLs added/changed, OCPS stapling support has been removed, different intermediate issuers) but this does sounds like a private key problem.

If you just run the app on the target machine instead of importing with your own script that would remove one variable.

Some windows updates can have an effect on certs, but I assume you're just using latest updates.

Apologies for the slow reply, these aren't getting emailed to me for some reason.

Unfortunately the problem has come back on its own and is now affecting a lot more certs.
Sadly I can't run it on the target machine as that machine doesn't have outbound internet access.
I'm definitely using RSA. I did try switching to EC as a test but ran into the same issue

I'm copying the PFX file up to the target machine, and then using PSRemoting to import and install it. Is there some mechanism that renders the private key unreadable if you do that? As I understand it the private key is embedded in the PFX and then you just need the password to read it?

I'm copying the PFX file up to the target machine, and then using PSRemoting to import and install it. Is there some mechanism that renders the private key unreadable if you do that? As I understand it the private key is embedded in the PFX and then you just need the password to read it?

I'm not sure about this specific issue, but I have experience with Powershell Remoting and I can tell you that remoting to a server (even with an admin credential) gives you less access rights then using the same credential locally. I've run into this not only with certificate stores, but also GAC (global assembly cache), Windows Update, and other subsystems.

The weird thing here is that thing presumably worked before and now they don't anymore. Have you been able to pin this to any specific software version?

Woohoo! that fixed it! Thank you so much!

I think there might be a discrepancy between the documentation and the software:

Emtpy - Equivalent to "legacy" for backwards compatibility.

I didn't have the ProtectionMode setting in my settings.json at all, because my config pre-dates this, and it's reverted to "default" not "legacy". I suspect the intent of setting it like this should also include the case where the setting is completely missing.

I see that RC2-40 is no-longer considered secure, althrough it's probably not the end of the world since all the decryption keys are on this box anyway, are there any other algorithms that are but can still be used on server 2016. Most of the stuff I saw when trying to debug this said to use 3DES, but I see that's not supported here and also not secure. I guess I need to push for getting rid of Server 2016! :D

True, the empty value is interpreted differently for the cache folder than for store plugins (central ssl and pfxfile) but the doc is copy-pasted. I thought this extra default protection for the cache would be safe enough, but you found an edge case with the remoting 😄. I'll have to think a bit about possibly changing this though.