Move default Vault Location to \ProgramData

[RickStrahl]

Currently the default Vault is located in %appdata%\letsencrypt-win-simple which is a user specific location which can cause problems with scheduled tasks as a user profile is required to gain access to this folder.

Seems like it would be a better idea to use a central location like \ProgramData to hold the default vault so that renewals and command line operations can be run from any account.

[rkerber]

I think the reason it was under the user's app data folder is because each registration to the ACME server requires an email address. With it under the user's folder each user could get notifications on their certificates expiry. If it was under a central location, then only 1 email address would get alerts for all certificate expiry notifications. There are probably reasons why people want both options so it could go either way.

Right now you can specify a different location for the certificates it generates, but that could be reworked to allow the entire config folder to be moved. I feel that this should be an option or everyone currently using the application might have to re-register and that will mess up renewals.

[RickStrahl]

But you can create multiple registrations in a single vault I think so the folder should have no impact on the email address. You would need an option to specify the email address as part of the command line or config options though to trigger that.

Agree though - if the path is configurable this isn't a big issue but I don't see that option currently. It looks like the docs are out of date for command line options (--manualhost --webroot options aren't there for example).

[rkerber]

You can only create 1 registration per Base URI that you use right now. There would have to be more changes to support having multiple registration files.

As I had stated the path is configurable for the certificates that are normally stored in that location and with a bit of tweaking that could be reused to move all of the config.

Those had been added a long time ago and I guess nobody ever added them to the Wiki page. However, you can see examples of them here.

I'm adding a few more arguments now, so i'll update the arguments Wiki page after I get them added.

[ebekker]

Just to give my $0.02, in the ACMESharp library, with the 0.8 release, I moved to a "Profile" mechanism, that allows you to create multiple Vaults (one with each Profile). Along with that is the default Profile which is implicitly stored in the \ProgramData folder if you run with Admin privileges, and in the user's %LOCALAPPDATA% if you don't.

All of the PowerShell cmdlets take an optional Profile name to override which Vault they operate on, which by default goes to the default Profile. I think this has turned out to be a good compromise for flexibility without overly complicating things.

[Trapulo]

I also will appreciate a way to have a "per server" way to store data (for example a flag so save them under the executable folder). I'd like to install the program on our servers, schedule renewals and so on, and allow any server administrators to manage it. A "per user" scenario is a big problem and trouble in a company environment.
thanks

[rkerber]

If anyone wants to see this enhancement, add your +1 (via add your reaction) to the first comment of this issue.

[Elemecca]

Using the user's ApplicationData folder can also be a security issue: it's part of the roaming profile, so if the user is a domain user their registration key will end up getting synced to the DC and every other domain-joined machine they log into. If it's a dedicated production domain that might actually be wanted, but if the domain is shared with workstations it could result in super-easy key compromise if any single machine they've logged into is compromised with a RAT trojan.

We should at least have the option to keep the config directory local.

[richard-browne]

Add my vote. To me it makes no sense at all to store the config data under C:\Users\account. An IIS web site is not per user. We have multiple admins on our server. If adminA logs in and configures letsencrypt, adminB will login and won't be able to run letsencrypt.exe. If adminA leaves, his account is deleted from the server, and everything breaks.

The correct location for config data is C:\ProgramData.

Similarly, the scheduled task should not run as the user who happened to run letsencrypt.exe first. It should run as SYSTEM by default.

[LBegnaud]

to add to what @richard-browne says. Every server I've configured has been done by using "psexec -i -s" to make LE-win-simple run as system.

[murray-grant-fe]

I've created a fork with the minimal changes required to change the vault location (which works in our corporate environment).

No attempt to address security or email issues raised.

https://github.com/murray-grant-fe/letsencrypt-win-simple

[nul800sebastiaan]

This should be fixed in v2 where the configpath is configurable on the command line - #394

[WouterTinus]

#483