certbot / certbot

Certbot is EFF's tool to obtain certs from Let's Encrypt and (optionally) auto-enable HTTPS on your server. It can also act as a client for any other CA that uses the ACME protocol.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

fullchain.pem cannot be accessed after restart on Windows 11

cgrguy opened this issue · comments

My operating system is (include version):

Windows 11

I installed Certbot with (snap, OS package manager, pip, certbot-auto, etc):

https://dl.eff.org/certbot-beta-installer-win32.exe

I ran this command:

certbot certonly --webroot

and it produced this output:

Before restarting Windows everything works as expected but after a restart fullchain.pem can no longer be read by server.

The problem is described here by SamLowryMOI. The problem seems to be that during creation the permission is assigned to a temporary user that is destroyed after a Windows reboot.

The temporary solution was to give the permission given to user LogonSessionId_#_###### to user MyPc\ItsMe.

Is this the same issue as tracked by #9165 then? If so, I think we should close this and track things there. If not, can you explain the difference to me?

The issue I experienced is the same issue described by SamLowryMOI, although I'm not sure if it is caused by "Controlled Folder Access" breaking Certbot. An additional detail from my case is the permissions for privkey.pem is set "correctly" (includes the MyPc\ItsMe user) by cerbot for it to be read by the server running as MyPc\ItsMe.
Upon further reading I'm also not sure if it's the case that Windows users are not expected to run the server under MyPc\ItsMe user, or if this is really a bug. Any information would be appreciated.
Please close or redirect this issue as you see fit.

Upon further reading I'm also not sure if it's the case that Windows users are not expected to run the server under MyPc\ItsMe user.

If there's a standard practice here for Windows sysadmins, I'm personally unfamiliar with it unfortunately.

Thanks for following up with the additional info. It may be slightly different, but I'm going to lump this problem in with the other Windows file permission issues in #9165 and close this. Thanks again.