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.
The following certificates are not due for renewal yet:
C:\Certbot\live\federate.derby-college.ac.uk\fullchain.pem expires on 2023-05-29 (skipped)
All renewals failed. The following certificates could not be renewed:
C:\Certbot\live\idp.derby-college.ac.uk\fullchain.pem (failure)
My web server is (include version): Jetty
The operating system my web server runs on is (include version): Windows Server 2019
I can login to a root shell on my machine (yes or no, or I don't know):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.2.0
Hello @talanwestby, welcome to the Let's Encrypt community.
I am no expert with Certbot on Windows! But guess (probably wrong) is it looks like a file access control on the Windows Server 2019 machine. So is Cetbot being run as the proper Windows User (i.e. possibly was installed by Administrator and now being run by a regular User)?
Kindly wait for more knowledgeable Let's Encrypt community volunteers to assist.
It was installed by me and I am a local administrator on the server and an enterprise administrator within our internal domain so there shouldn't be any permission issues. I have also confirmed that C:\Certbot I have write access to in the folder permissions. I am also the one who ran the renew command so I cannot see what should be denying my access. I also ran the CMD as an administrator. Thanks.
Certbot creates a scheduled task for renewals in Windows Task Scheduler. Check that's setup to run as Administrator with Run with highest prvilieges.
A common issue is that the files in C:\Certbot\live\* are symbolic links to the actual files in C:\Certbot\archive\ and if the application server using the files doesn't have read permission on the archive files then it won't be able to consume the file via the symbolic link. Could be that.
To update you, the renewals were done by me, and all of them are trying to get this to work. I then noticed that our version of certbot was 1.24 so I upgraded it to 2.2 yesterday from the website.
I can confirm that all of the administrators have rights to the folder C:\Certbot and inherits down. I've just tried again this morning with the same permission error running it as myself under CMD for Administrator.
There are also ongoing discussions for certbot regarding Windows permissions:
When running CMD as Administrator are you able to successfully run more C:\Certbot\live\federate.derby-college.ac.uk\fullchain.pem and see the pem file contents? If not that would still be a permissions block on the linked file.
If you can access the file OK from CMD then that implies there is something preventing python from performing file operations and I would suspect Controlled Folder Access: Evaluate controlled folder access | Microsoft Learn
Just an update on this. it does look like the cert bot was behaving as expected. I ended up finding another piece of the Certbot puzzle which is under C:\Certbot\renewal-hooks\post. It turns out there is a BAT file in here that was owned and run by someone who has left the organisation. Changing permission on this file has fixed our user facing issue. I'm hoping it'll resolve the full renewal when it takes place in a couple of months. I'll set a reminder now and if I don't update here assume it was just this BAT file that needed changing.
Good find. Just a note you can test the renew right now using
certbot renew --dry-run
It will run hooks and do domain verification but won't disturb your production certs. Using the Staging system (--dry-run) is also not subject to rate limits (very much) so is good to use anytime you start running into problems.
