When Certbot first requests a cert, the cert files are named <cert/chain/fullchain/privkey>1.pem, and this is generally fine, assuming that when the renewal process takes place the existing cert becomes <cert/chain/fullchain/privkey>2.pem (or whatever the next number in sequence is) and the new (renewed) cert takes over as <cert/chain/fullchain/privkey>1.pem, so that any configuration files referencing the <cert/chain/fullchain/privkey>1.pem files don't also need to be updated each time the cert is renewed. This, however, doesn't work in this way; the new (renewed) cert is named <cert/chain/fullchain/privkey>2.pem (or whatever the next number in sequence is), meaning that configuration files that reference the cert files directly need to be updated to use the new cert rather than it being effectively automatic.
Is there a way to either overwrite the existing cert files rather than make a new set, or to give custom names when the renewal process is taking place (such as <cert/chain/fullchain/privkey>.current.pem and <cert/chain/fullchain/privkey>.date-retired.pem?
My domain is: Not applicable
I ran this command: Not applicable
It produced this output: Not applicable
My web server is (include version): Kestrel
The operating system my web server runs on is (include version): Windows Server 2022
My hosting provider, if applicable, is: Not applicable
I can login to a root shell on my machine (yes or no, or I don't know): Not applicable
I'm using a control panel to manage my site (no, or provide the name and version of the control panel): Not applicable
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 2.9.0
I'm very confused by your question. Servers should be referencing the files in live/<cert-name>/, which are symbolic links to the historic files that you're currently looking at. (See "Where are my Certificates?" in the documentation.)
But if you're on Windows, then you don't want to be using Certbot anyway. There's probably an easier way for whatever server you're trying to configure using a Windows-native client.
Also, it very much has a "linuxy" approach to how it does things. It uses symbolic links, it assumes that servers will be configured by pointing to the pem files, etc. Windows-native software usually expects certificates to be in the OS's certificate store and managed as separate things, not really as files. If you were running Apache on Windows, say, it'd be alright, but if you're trying to use .NET and IIS and such it's going to be working against you.
If you need to use certbot, then I think you'd want to write a deploy-hook that copies the files from the live folder to some other place, and have your server software point at that place, if the software can't use the symbolic links directly for some reason (which seems odd to me too).
But you're probably much better off using win-acme or Certify the Web, which are written specifically for Windows and how Windows servers want to integrate with their certificates.
I see. Thank you for the explanation about Certbot and its limitations on Windows. I'll give the other clients a look as a replacement.
With Kestrel, I can have it use certificates in a few different ways:
PFX Certificates
Certificate Store by Subject
Certificate Store by Thumbprint
PEM And Key Certificates
I was trying to avoid options 2 and 3 to avoid having to first install the cert in the store as a separate task. Option 1 is fine, but also has the additional task of needing to generate a PFX file out of the PEM files Certbot (or whichever) generates. Option 4 is where I landed, but that brings in the filename issue I initially mentioned.
It sounds like you may need a step in between the issuance and when Kestrel picks up the latest cert.
That step can simply copy the symlinked files to a standard location for Kestrel to pick them up [overwriting the previous files].
Those kinds of "steps" are known as hooks.
In this case, you best choice would be a deployment hook [which would only kick in when a cert is actually renewed - not everytime the client is run].
1- CertifyTheWeb
2- Run a server like Caddy in front of Kestrel as a gateway server; Caddy will download and manage the certificates for you, and handle all the ssl stuff
3- If you want to continue using Certbot, you can use a "--deploy-hook" to run a custom script after getting the certificates to unversion them.
In one of my projects, I have a short script written in Fabric that analyzes my LetsEncrypt datastore and repackages the new files into unversioned filenames within versioned directory names, then enrolls them all into a git repository secured by Blackbox encryption.
