Overriding cert paths

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: 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?

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.


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!

1 Like

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.

And you can always use certbot hooks to copy certificates, keys and chains wherever you want.


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).

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) 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).


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.

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 ...


You can also probably set certbot to produce whatever it is you need :wink:

You shouldn't use a CSR unless you have to (ie, some appliance gives you one to get signed).


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.

Why shouldn't I create my own with openssl?

Is there something certbot is doing that I cannot do?

No, but it's a lot easier to leave it to certbot. It's incredibly configurable, there is no reason not to.


I have my reasons, which means there are some reasons. :slight_smile:

In any case, my conclusion was confirmed, and that's really what I was looking for here.

Thank you! :slight_smile:

1 Like

If you tell us what they are, we can tell you if certbot has an appropriate option for that. :smiley:


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))

  • 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.


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.

1 Like

Certbot does not claim that. Nobody claims that with Certbot.

I can't think of any applications that support usage patterns like that.


That was claimed in this thread.

1 Like

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.

I did. :smiley:


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.