Controlling Certificate Names and CSRs - Which Client to Use

I’m just needing a little guidance… perhaps someone can help. I need a client that I can set up to automatically renew my certificate via a cron job, or what have you, that will allow me to specify the output certificate names, and will accept the use of a certificate signing request, all without a web server being run. I have tried certbot-auto on Debian 8, which works, but the output certificate names are somewhat random so I would need to write a script to copy those certificates to the correct location. Certbot-auto works perfect as far as actually renewing the certificate, but it doesn’t appear it offers the ability to specify output certificate names which is something I need. Does anyone know of any clients that would fit this need? Allows use of CSR, and output certificate names, without running a web server on the machine(i.e. standalone mode)? Thank you in advance. This is a fantastic product you have here.

I believe would be able to do this

See the main documentation for how to tell the shell script the filenames you want for things

Thanks. I got up and running. All appears well, appreciate the tip on It does what it says it will. I have noticed some people prefer generating a new private key with each certificate renewal. I noticed the script checks for the presence of a csr file and then signs from that csr if it exists. I’m assuming that at each renewal, it will reuse that CSR with the updated certificate? If I were to opt out of using my own CSR, would it reissue a new key each time it renews?

hi @cr9c1

There are a couple of challenges with what you are proposing that I would like to outline

A) CSRs are linked to private keys. In cryptography it’s basically a way of saying for given domains I would like to use RSA or ECC key x to represent domains Y
B) Good Practices are to renew ECC or RSA domain keys on each renewal
C) Why are you trying to keep the same CSR - I understand there may be valid reasons but please articulate your reasons
D) Certbot will support what you want

Arguments changing execution paths & servers

–cert-path CERT_PATH
Path to where cert is saved (with auth --csr),
installed from, or revoked. (default: None)
–key-path KEY_PATH Path to private key for cert installation or
revocation (if account key is missing) (default: None)
–fullchain-path FULLCHAIN_PATH
Accompanying path to a full certificate chain (cert
plus chain). (default: None)
–chain-path CHAIN_PATH
Accompanying path to a certificate chain. (default:
–config-dir CONFIG_DIR
Configuration directory. (default: /etc/letsencrypt)
–work-dir WORK_DIR Working directory. (default: /var/lib/letsencrypt)
–logs-dir LOGS_DIR Logs directory. (default: /var/log/letsencrypt)
–server SERVER ACME Directory Resource URI. (default:


It could easily be for embedded devices or public-key pinning, neither of which is very objectionable. :slight_smile:

I’ve suggested that changing keys regularly helps if you have, for example, frequent or occasional negotiation of non-forward-secret ciphersuites, but unfortunately Certbot currently fails to then destroy the old keys, meaning that we don’t really get the full benefit. (It’s more credible that an adversary would compromise a server to steal the old private keys on it than that the adversary would use some super-expensive unknown cryptanalytic attack to derive them from the old public keys.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.