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.
I ran this command: certbot certonly -c vzxy.net.ini
It produced this output: success
My web server is (include version): N/A
The operating system my web server runs on is (include version): Rocky 8 (~ RHEL 8)
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): No
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): 1.22
I've played around with this for a bit, and it seems that if I override any of the path settings, mainly csr/key, the live/renewal/archive dirs won't be used and I am on my own with renewals, having to use certonly again for each domain. That is, if I want 'renew' to work, I am basically forced to let LE manage the csr/creation and cert issuance entirely where it wants to (with only config-dir as a rough way to put things 'sort of' where I want to).
Right. That's what I finally figured out. LE wants to absolutely control all files if I want to do renewals or list certs. That's unfortunate, since I'd rather generate csr/key myself and be able to put specific cert files (e.g. cert/chain files) in specific places.
(Yes, my .ini file above is complete and works fine)
That's Certbot's behavior - not LetsEncrypt - and tied to your decision to use the CSR.
Certbot will let you pass in an alternate path for reading config files and saving data to, via --config-dir (i.e. override /etc/letsencrypt). If you are dealing with persistent storage or networked volumes, that is often a great option. (You can also override the logs and working directory).
Please note: Many people use the post success hooks in certbot to deploy the certificates where they desire (e.g. copying onto other servers, the cloud, or other directories).
Overriding or not, the config still points to a set of files that could easily be examined instead of bailing because there's no use of a live dir or versioning. I can't see how overriding should have any impact on a simple way to renew a set of certs.
If you are competent with openssl and wish to handle things with it, you should use openssl and another client – or write custom code.
If you think of this in terms of the 80/20 rule, Certbot provides 20% of possible functionality - which is is the perfect solution for 80% of potential users. Their development team decided to not support advanced use cases like this, because "power users" can handle it otherwise and it creates additional work to maintain and handle bugs with.
That being said, CSRs are relatively worthless in ACME v2.
A user creates an order on the API, listing the domains
A user successfully answers the challenges for each domain
When all are valid, a CSR is generated based on the order details - and then submitted to the API to finalize the order
When a CSR is used by Certbot or another client, it's really only used to do 2 things:
Extract data to submit to the API for the order
Assert private key ownership
IIRC, both Certbot and ACME servers will ignore most unsupported fields in a CSR. Certain fields or extensions in a CSR will cause a failed order. The servers also require CSRs to be formatted in specific ways, regarding how domains are listed and some specific content.
I was really just surprised by the rigidity of the layout. If cert-bot is incredibly configurable, then I should be able to say, "I want to generate my own csr/key, place my cert/chain files elsewhere, and disable versioning." I just want 'renew' to look at the cert file that I've specified in my .ini file and renew it if needed.
I am not expecting anything. It's a mostly, if not an all, volunteer effort, and I certainly get that, and I do appreciate it.
I think that if you can use "certonly --csr" to obtain a cert, you should then be able to "--reuse-key" on subsequent renewals [without having to use "--csr" again].
As for getting rid of versioning, I think you can include plenty to handle that within a "--deploy-hook".
I don't think so. Using --csr doesn't store any renewal configuration what so ever, so after using Certbot with --csr, Certbot is completely unaware of the issued certificate. It just dumps the cert and chain in the current directory or in the paths specified on the command line, but that's it.
