IIS Centralized certificates: "The profile for the user is a temporary profile"

[notken]

Hi there. Having been able to use letsencrypt on a test server, I'm now trying it in our load balanced, multi-server live environment which has centralized certificates (Win2012R2).

Command line is
letsencrypt.exe --test --centralsslstore "E:\Certificates"

(E is a local drive to this server, not a network drive; I've tried it on shares too with the same result.)

I've added the central password to the .config file.

It creates the pfx but in Centralized Certificates section of IIS Manager, there's a red x, it's marked as Expired and says "The profile for the user is a temporary profile".

I can't find anything relevant on Google.

Any idea what could be causing this?

Thanks for you help with this.

[m00nh3ck]

have you tried to run letsencrypt as a different user
go to start type Run then runas localadminuser cmd
then navigate to letscrypt and try to run it.

[notken]

Hi there. Thanks for the suggestion, but, yes, and just tried again and got the same issue.

[WouterTinus]

I remember reading somewhere (though I can't find it now) that it's related to the openssl library used by AcmeSharp and therefore LEWS. It was supposed to be harmless, i.e. the certificates should work.

[rdebath]

The private keys that you load into CertMan are NOT stored in the registry. They exist on the filesystem under the directory:

C:\Users\%USERNAME%\AppData\Roaming\Microsoft\Crypto\RSA

The "Computer" store is under

C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys

So if the profile for a particular user is temporary (missing) some of the private keys won't be available.

They also don't always get deleted; another reason for making sure that your PFS is working properly.

[WouterTinus]

@rdebath what do you mean by PFS? Is this something which LEWS could do better?

[WouterTinus]

This might be fixed with the updated ACMESharp library that will be landing into 1.9.7.

[rdebath]

PFS means 'perfect forward security'. Also known as "Forward Secrecy".

It's nothing to do with LE or LEWS directly, it's related to the cipher combinations that the SSL library negotiates with the web browser. When they both agree to use a suitable combination an encryption key is agreed on the fly between the two ends that only they know. What's more, once the connection has closed and they have deleted the 'session key' not even they can go back and decrypt a log of the connection. Even though the server has the private key for the certificate.

This means that IF all connections used (P)FS and all certificates using that key have expired the private key becomes completely useless (even to an attacker) as it was only ever used to authenticate the connection and never used to encrypt anything that went over the wire.

OTOH, normally, you have to be very sure to delete the private key from an old machine, you really don't want it left in a random (hidden) directory in a forgotten corner.

SSLLabs has a writeup about (P)FS ...
https://blog.qualys.com/ssllabs/2013/06/25/ssl-labs-deploying-forward-secrecy