Pywintypes.error: (5, 'CreateFile', 'Access is denied.') When Attempting to Create/Renew SSL Cert

[CommodoreKong]

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: commodorekong.duckdns.org

I ran this command: `certbot certonly --standalone -d commodorekong.duckdns.org

It produced this output: pywintypes.error: (5, 'CreateFile', 'Access is denied.')

My web server is (include version): N/A, using the software foundryvtt.

The operating system my web server runs on is (include version): Windows 11

My hosting provider, if applicable, is: N/A

I can login to a root shell on my machine (yes or no, or I don't know): Yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): N/A

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):certbot 1.24.0

I run a piece of software called FoundryVTT on a Windows 11 Mini PC that I have an SSL certificate from Lets Encrypt. I had followed the instructions on their site on setting up certbot and getting an ssl cert from letsencrypt.

When I first set this up and setup certbot it was on another computer, that computer started having problems randomly crashing and I had to return it and get another. I'm coming up on my first cert renewal and I never moved the files in the certbot folder, only the fullchain.pem and privkey.pem files that foundry uses. I've tried to renew and just create a commodorekong.duckdns.org cert and have been getting pywintypes.error: (5, 'CreateFile', 'Access is denied.') errors. My account is an admin account and I run the command in a command prompt running as admin.

I can post an entire logfile but it seems to go through most of the steps of making the ssl cert and then fails at this step:

2023-04-02 12:53:01,395:DEBUG:acme.client:Storing nonce: 371CFLPb3OxJmWmrkY-SGF_aYshEXkw1w66FqKWMqkHoQeU
2023-04-02 12:53:01,412:DEBUG:certbot._internal.log:Exiting abnormally:
Traceback (most recent call last):
File "runpy.py", line 197, in _run_module_as_main
File "runpy.py", line 87, in run_code
File "C:\Program Files (x86)\Certbot\bin\certbot.exe_main.py", line 29, in
sys.exit(main())
File "C:\Program Files (x86)\Certbot\pkgs\certbot\main.py", line 19, in main
return internal_main.main(cli_args)
File "C:\Program Files (x86)\Certbot\pkgs\certbot_internal\main.py", line 1679, in main
return config.func(config, plugins)
File "C:\Program Files (x86)\Certbot\pkgs\certbot_internal\main.py", line 1538, in certonly
lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
File "C:\Program Files (x86)\Certbot\pkgs\certbot_internal\main.py", line 139, in _get_and_save_cert
lineage = le_client.obtain_and_enroll_certificate(domains, certname)
File "C:\Program Files (x86)\Certbot\pkgs\certbot_internal\client.py", line 526, in obtain_and_enroll_certificate
return storage.RenewableCert.new_lineage(
File "C:\Program Files (x86)\Certbot\pkgs\certbot_internal\storage.py", line 1053, in new_lineage
config_file, config_filename = util.unique_lineage_name(
File "C:\Program Files (x86)\Certbot\pkgs\certbot\util.py", line 281, in unique_lineage_name
return safe_open(preferred_path, chmod=chmod), preferred_path
File "C:\Program Files (x86)\Certbot\pkgs\certbot\util.py", line 229, in safe_open
fd = filesystem.open(path, os.O_CREAT | os.O_EXCL | os.O_RDWR, *open_args)
File "C:\Program Files (x86)\Certbot\pkgs\certbot\compat\filesystem.py", line 247, in open
raise err
File "C:\Program Files (x86)\Certbot\pkgs\certbot\compat\filesystem.py", line 237, in open
handle = win32file.CreateFile(file_path, win32file.GENERIC_READ,
pywintypes.error: (5, 'CreateFile', 'Access is denied.')
2023-04-02 12:53:01,412:ERROR:certbot._internal.log:An unexpected error occurred:
2023-04-02 12:53:01,412:ERROR:certbot._internal.log:pywintypes.error: (5, 'CreateFile', 'Access is denied.')

[_az]

If you open C:\Certbot\ in Explorer and go to Properties → Security → Advanced → Administrators → Edit, what do your permissions look like?

Try setting "This folder, subfolders and files" with each Basic Permission ticked for the Administrator user:

@CommodoreKong

I never moved the files in the certbot folder, only the fullchain.pem and privkey.pem files that foundry uses

Do you mean you moved the files out of the folder? Or copied them?

[CommodoreKong]

I changed up the administrators permissions to this folder, sub-folders and files (it was set to this folder) and made sure everything was checked so it has full permissions.

Unfortunately I have to wait until tomorrow to give it a try again because I hit the limit on the number of requests I can make for my domain in a 168 hour period.

To clarify the section you quoted (sorry if it wasn't super clear):
I had originally setup certbot and got this SSL cert on a different computer. When that computer was failing and I moved over to a new computer I didn't copy my certbot folder over to the new computer before I wiped the old one. The only files I had from the original SSL cert were fullchain.pem and privkey.pem since those files were in my FoundryData folder since the Foundry service needs those files for the SSL cert (SSL and HTTPS | Foundry Virtual Tabletop)

I did try to recreate the C:\certbot\live\commodorekong.duckdns.org folder and put the fullchain/pem and privkey.pem in there and do a renewal before running the full certbot certonly --standalone -d YOURDOMAINNAMEHERE command to see if it would let me renew with just those 2 files. I doubted I had everything I needed for the renewal with just those 2 files and it didn't work, which is why I just attempted using the `certbot certonly --standalone -d commodorekong.duckdns.org to generate a full new set of files and SSL cert however I started running into the createfile error described in my topic when I did that.

[Osiris]

@CommodoreKong

Unfortunately I have to wait until tomorrow to give it a try again because I hit the limit on the number of requests I can make for my domain in a 168 hour period.

Please use the staging environment for testing.

[danb35]

@CommodoreKong

Unfortunately I have to wait until tomorrow to give it a try again because I hit the limit on the number of requests I can make for my domain in a 168 hour period.

If I'm not mistaken, the only rate limit that specifies a period of 168 hours is the one for issued certs--so you've already successfully issued five certs for the identical set of domains within the past weeks.

[CommodoreKong]

@Osiris

Please use the staging environment for testing.

Well I just tried the staging environment by running it with the --test-cert and that worked so I'll give it a try tomorrow when I can.

@danb35

If I'm not mistaken, the only rate limit that specifies a period of 168 hours is the one for issued certs--so you've already successfully issued five certs for the identical set of domains within the past weeks.

Yeah just looking at the logs it looks like the SSL cert is being created (the log appears to have the SSL cert information in it), however it errors out with the file permission error when trying to write files and nothing shows up C:\certbot\live\

[_az]

@CommodoreKong

I did try to recreate the C:\certbot\live\commodorekong.duckdns.org folder and put the fullchain/pem and privkey.pem in there

I am not surprised that you've ended up with the CreateFile error after doing that.

As general advice, manually creating/modifying the directories within C:\Certbot isn't a good idea because Certbot creates them with specific directory ACLs on Windows. Those ACLs are lost if you create those directories by hand.

I'm not sure whether there's a great way to fix the directory permissions if you've modified them in any significant way, other than starting from scratch with a new C:\Certbot directory.

Unfortunately, the rate limit error you're currently experiencing won't go away until a week has elapsed, even if you do that.

[CommodoreKong]

@_az

I am not surprised that you've ended up with the CreateFile error after doing that.

As general advice, manually creating/modifying the directories within C:\Certbot isn't a good idea because Certbot creates them with specific directory ACLs on Windows. Those ACLs are lost if you create those directories by hand.

I'm not sure whether there's a great way to fix the directory permissions if you've modified them in any significant way, other than starting from scratch with a new C:\Certbot directory.

Unfortunately, the rate limit error you're currently experiencing won't go away until a week has elapsed, even if you do that.

Ohh good to know. Learning experience I guess, this is the first time I've ever really created/renewed SSL certs. When I'm able to try again I can uninstall certbot, make sure the C:Certbot directly is fully cleaned out, reinstall and try again.

[CommodoreKong]

@_az

I am not surprised that you've ended up with the CreateFile error after doing that.

As general advice, manually creating/modifying the directories within C:\Certbot isn't a good idea because Certbot creates them with specific directory ACLs on Windows. Those ACLs are lost if you create those directories by hand.

I'm not sure whether there's a great way to fix the directory permissions if you've modified them in any significant way, other than starting from scratch with a new C:\Certbot directory.

Unfortunately, the rate limit error you're currently experiencing won't go away until a week has elapsed, even if you do that.

I uninstalled Certbot, deleted the C:\Certbot directory and reinstalled and was able to get a new SSL cert. Thank you very much for the assistance!

[schoen]

@_az

As general advice, manually creating/modifying the directories within C:\Certbot isn't a good idea because Certbot creates them with specific directory ACLs on Windows. Those ACLs are lost if you create those directories by hand.

I sort of wish the IT world had a strong, well-known convention like

README.noreallythisdirectorycontainsstructureddataormagicfilenamesthatwillconfusesoftwareifyoumodifythem

or maybe

README.hicsuntdracones

whereby it was straightforward to warn people that modifying the contents of a directory would very likely break software. (Ideally, the contents of that README would also then tell readers where to find documentation on how to modify the contents safely, including all of the permissions/validation/locking/referential integrity constraints that might apply.)

[rg305]

README.NoUserServiceablePartsInsideEnterAtYourOwnRisk