# Overriding cert paths **URL:** \ **Category:** Help\ **Created:** [August 3, 2023, 9:21pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940 "2023-08-03T21:21:42Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 9:21pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/1 "2023-08-03T21:21:42Z")
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](https://crt.sh/?q=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: [vzxy.net](http://vzxy.net) 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). Have I come to the correct conclusion? ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 9:27pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/2 "2023-08-03T21:27:51Z")
The `-c` command line option tells certbot to use an alternative configuration file. Is this your intention? Ok, it is. You still have to tell certbot what to do, after giving it a configuration file. And if you give certbot a CSR every possible automation goes out of the window. ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 9:35pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/3 "2023-08-03T21:35:28Z")
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) Thanks for the confirmation! ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 9:38pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/4 "2023-08-03T21:38:27Z")
It doesn't "want" -- certbot just has no way of knowing what you require, when using your own CSR. If you find certbot too invasive, there are [alternatives](https://letsencrypt.org/docs/client-options/). And you can always use certbot hooks to copy certificates, keys and chains wherever you want. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [August 3, 2023, 9:48pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/5 "2023-08-03T21:48:00Z")
> [@bchill](#): > > 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. 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). > [@bchill](#): > > 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. Certbot is probably not the client for you. You may be able to use acme.sh ([GitHub - acmesh-official/acme.sh: A pure Unix shell script implementing ACME client protocol](https://github.com/acmesh-official/acme.sh)) for your needs. Otherwise, you may need to piece together something custom using the various ACME libraries available for many programming languages. 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). ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 9:48pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/6 "2023-08-03T21:48:27Z")
It would be easy enough for a 'renew' combined with paths listed in a .ini file to examine the expiration date in the cert file and renew if needed. ---
**Author:** ![MikeMcQ](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/mikemcq/32/52772_2.png) [@MikeMcQ](https://community.letsencrypt.org/u/MikeMcQ)\ **Post date:** [August 3, 2023, 9:52pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/7 "2023-08-03T21:52:26Z")
> [@bchill](#): > > It would be easy enough for a 'renew' combined with paths listed in a .ini file That is exactly how Certbot behaves by default. After a successful cert request it creates a conf file in .../renewal for use by its `renew` subcommand But, as noted once you start overriding things ... ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 9:52pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/8 "2023-08-03T21:52:32Z")
You can also probably set certbot to produce whatever it is you need 😉 You shouldn't use a CSR unless you _have to_ (ie, some appliance gives you one to get signed). ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 10:01pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/9 "2023-08-03T22:01:01Z")
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. ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 10:02pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/10 "2023-08-03T22:02:07Z")
Why shouldn't I create my own with openssl? Is there something certbot is doing that I cannot do? ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 10:07pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/11 "2023-08-03T22:07:02Z")
No, but it's a lot easier to leave it to certbot. It's incredibly configurable, there is no reason not to. ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 10:08pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/12 "2023-08-03T22:08:50Z")
I have my reasons, which means there are some reasons. 🙂 In any case, my conclusion was confirmed, and that's really what I was looking for here. Thank you! 🙂 ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 10:09pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/13 "2023-08-03T22:09:40Z")
If you tell us what they are, we can tell you if certbot has an appropriate option for that. 😃 ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [August 3, 2023, 10:16pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/14 "2023-08-03T22:16:42Z")
> [@bchill](#): > > I can't see how overriding should have any impact on a simple way to renew a set of certs. > [@bchill](#): > > Why shouldn't I create my own with openssl? 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. The way ACME V2 works (see [RFC 8555 - Automatic Certificate Management Environment (ACME)](https://datatracker.ietf.org/doc/html/rfc8555#section-4)) - 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: 1. Extract data to submit to the API for the order 2. 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. ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 10:19pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/15 "2023-08-03T22:19:43Z")
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. ---
**Author:** ![jvanasco](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/jvanasco/32/55900_2.png) [@jvanasco](https://community.letsencrypt.org/u/jvanasco)\ **Post date:** [August 3, 2023, 10:22pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/16 "2023-08-03T22:22:20Z")
> [@bchill](#): > > If cert-bot is incredibly configurable, Certbot does not claim that. Nobody claims that with Certbot. > [@bchill](#): > > "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 can't think of any applications that support usage patterns like that. ---
**Author:** ![bchill](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/bchill/32/72485_2.png) [@bchill](https://community.letsencrypt.org/u/bchill)\ **Post date:** [August 3, 2023, 10:27pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/17 "2023-08-03T22:27:10Z")
> [@9peppe](#): > > No, but it's a lot easier to leave it to certbot. It's **incredibly configurable** , there is no reason not to. That was claimed in this thread. ---
**Author:** ![9peppe](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/9peppe/32/31596_2.png) [@9peppe](https://community.letsencrypt.org/u/9peppe)\ **Post date:** [August 3, 2023, 10:27pm UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/18 "2023-08-03T22:27:12Z")
Certbot has an option to reuse the private key, if you so desire. I don't recall if you can give it your own, tho. You can place your files anywhere you want, just think of `/etc/letsencrypt` as certbot-internal, and place your files with `--deploy-hook`. > [@jvanasco](#): > > Nobody claims that with Certbot. I did. 😃 ---
**Author:** ![rg305](https://sea3.discourse-cdn.com/letsencrypt/user_avatar/community.letsencrypt.org/rg305/32/91314_2.png) [@rg305](https://community.letsencrypt.org/u/rg305)\ **Post date:** [August 4, 2023, 1:50am UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/20 "2023-08-04T01:50:22Z")
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`". ---
**Author:** ![Osiris](https://avatars.discourse-cdn.com/v4/letter/o/839c29/32.png) [@Osiris](https://community.letsencrypt.org/u/Osiris)\ **Post date:** [August 4, 2023, 6:12am UTC](https://community.letsencrypt.org/t/overriding-cert-paths/202940/21 "2023-08-04T06:12:28Z")
> [@rg305](#): > > 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]. 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. [Next page](https://community.letsencrypt.org/t/overriding-cert-paths/202940.md?page=2)