per-certificate config files #40

Closed
opened 2025-12-29 00:23:05 +01:00 by adam · 11 comments
Owner

Originally created by @lukas2511 on GitHub (Jan 22, 2016).

It would be nice to have additional config files per-certificate to allow for certificate-specific options like RENEW_DAYS and PRIVATE_KEY_RENEW.

This replaces issue #34.

Originally created by @lukas2511 on GitHub (Jan 22, 2016). It would be nice to have additional config files per-certificate to allow for certificate-specific options like RENEW_DAYS and PRIVATE_KEY_RENEW. This replaces issue #34.
adam added the enhancementhelp wanted labels 2025-12-29 00:23:05 +01:00
adam closed this issue 2025-12-29 00:23:05 +01:00
Author
Owner

@srvrco commented on GitHub (Jan 23, 2016):

Any specific location in mind ? how about in the ${BASEDIR}/certs/${domain}/ folder then each cert domain could overwrite the defaults set in the main config ( if it needed anything different ) and just use the defaults if not.

have a quick look at https://github.com/srvrco/getssl - I wrote it primarily because I wanted different defaults on different domains, and also wanted to be able to copy the challenges and final certs to remote servers ( ssh / scp) ..... If you are happy for that additional functionality - I can look at adding multiple configs and effectively combining ( separate configs per domain / remote servers ) in to your script ? (and effectively removing mine )

@srvrco commented on GitHub (Jan 23, 2016): Any specific location in mind ? how about in the ${BASEDIR}/certs/${domain}/ folder then each cert domain could overwrite the defaults set in the main config ( if it needed anything different ) and just use the defaults if not. have a quick look at https://github.com/srvrco/getssl - I wrote it primarily because I wanted different defaults on different domains, and also wanted to be able to copy the challenges and final certs to remote servers ( ssh / scp) ..... If you are happy for that additional functionality - I can look at adding multiple configs and effectively combining ( separate configs per domain / remote servers ) in to your script ? (and effectively removing mine )
Author
Owner

@lukas2511 commented on GitHub (Jan 23, 2016):

Yea, I was thinking to allow for config.sh next to the certificates in the target directory.

For implementation I guess the best thing would be to move certificate-specific code to a new function and use local variables, but this has to be implemented clean, variables should never be carried over to the next call of the function, because that would mess with other certificates.

@lukas2511 commented on GitHub (Jan 23, 2016): Yea, I was thinking to allow for `config.sh` next to the certificates in the target directory. For implementation I guess the best thing would be to move certificate-specific code to a new function and use `local` variables, but this has to be implemented clean, variables should never be carried over to the next call of the function, because that would mess with other certificates.
Author
Owner

@srvrco commented on GitHub (Jan 23, 2016):

agreed. I'm away this weekend - I'll take a closer look at your code early next week.

@srvrco commented on GitHub (Jan 23, 2016): agreed. I'm away this weekend - I'll take a closer look at your code early next week.
Author
Owner

@iiidefix commented on GitHub (Feb 3, 2016):

I would prefer to have a set of certificates with the same settings without creating a config for every certificate that is different from the main config but identical with at least some other configs.

Two ideas to make this possible:

  1. Make the domains.txt customisable via config.sh. This allows to run letsencrypt.sh first with default settings and domains.txt. And then run it again with -f config2.sh which points to domains2.txt.
  2. Extent the syntax of domains.txt. Add a line starting with a character not allowed in domains (e.g. a colon : ). And point to a custom config.sh which merges with the current config and is valid for all following domains.

In every scenario using multiple configuration files we should add a debug option which just outputs all configuration values per certificate(set) and does nothing else.

@iiidefix commented on GitHub (Feb 3, 2016): I would prefer to have a set of certificates with the same settings without creating a config for every certificate that is different from the main config but identical with at least some other configs. Two ideas to make this possible: 1. Make the `domains.txt` customisable via `config.sh`. This allows to run `letsencrypt.sh` first with default settings and `domains.txt`. And then run it again with `-f config2.sh` which points to `domains2.txt`. 2. Extent the syntax of `domains.txt`. Add a line starting with a character not allowed in domains (e.g. a colon `:` ). And point to a custom `config.sh` which merges with the current config and is valid for all following domains. In every scenario using multiple configuration files we should add a debug option which just outputs all configuration values per certificate(set) and does nothing else.
Author
Owner

@srvrco commented on GitHub (Feb 3, 2016):

I was thinking more of a priority system, so in effect there are defaults within the code ( if no config files are specified ). The main config file could then be used to modify this default. Anything at the certificate level would use these unless there was a value in a certificate specific config file which would overwrite the earlier values.

@srvrco commented on GitHub (Feb 3, 2016): I was thinking more of a priority system, so in effect there are defaults within the code ( if no config files are specified ). The main config file could then be used to modify this default. Anything at the certificate level would use these unless there was a value in a certificate specific config file which would overwrite the earlier values.
Author
Owner

@lukas2511 commented on GitHub (Feb 5, 2016):

Yes, idea was to have those specific configs as optional config files overriding some parameters for a single certificate, not having them as a requirement.

@lukas2511 commented on GitHub (Feb 5, 2016): Yes, idea was to have those specific configs as optional config files overriding some parameters for a single certificate, not having them as a requirement.
Author
Owner

@iiidefix commented on GitHub (Feb 5, 2016):

I like the idea to overwrite parameters for a single certificate.
Additionally it would be great to have the possibility to overwrite specific parameters for a group/set of certificates at once.
The reason for this are two domains registered by different resellers with different DNS-APIs.

  • http-01 as default verification method for
    • example.com www.example.com
    • example.net www.example.net
    • webmail.example.com
  • dns-01 with hook1.sh for DNS-API1:
    • smtp.example.com
    • imap.example.com
  • dns-01 with hook2.sh for DNS-API2:
    • ipv6-only.example.net

With this setup it would be great to have two independent hooks. One for challenge handling and another one for certificate deployment and service restart. So we can specify challenge handling at group level and certificate deployment for every certificate.

@iiidefix commented on GitHub (Feb 5, 2016): I like the idea to overwrite parameters for a single certificate. Additionally it would be great to have the possibility to overwrite specific parameters for a group/set of certificates at once. The reason for this are two domains registered by different resellers with different DNS-APIs. - http-01 as default verification method for - example.com www.example.com - example.net www.example.net - webmail.example.com - dns-01 with hook1.sh for DNS-API1: - smtp.example.com - imap.example.com - dns-01 with hook2.sh for DNS-API2: - ipv6-only.example.net With this setup it would be great to have two independent hooks. One for challenge handling and another one for certificate deployment and service restart. So we can specify challenge handling at group level and certificate deployment for every certificate.
Author
Owner

@lukas2511 commented on GitHub (Feb 10, 2016):

Well, you could always use symlinks to have a shared config for multiple certs.

But maybe this could also be implemented with the help of a hook script so that people could script this...

@lukas2511 commented on GitHub (Feb 10, 2016): Well, you could always use symlinks to have a shared config for multiple certs. But maybe this could also be implemented with the help of a hook script so that people could script this...
Author
Owner

@basbebe commented on GitHub (Feb 11, 2016):

+1
I would love to set different locations and hooks for certain domains

@basbebe commented on GitHub (Feb 11, 2016): +1 I would love to set different locations and hooks for certain domains
Author
Owner

@basbebe commented on GitHub (Feb 18, 2016):

I like this idea a lot.
For certain domains it might even be good to have a RSA and an ECDSA key available:
http://www.postfix.org/TLS_README.html
Would be great to have this choice too.

@basbebe commented on GitHub (Feb 18, 2016): I like this idea a lot. For certain domains it might even be good to have a RSA and an ECDSA key available: http://www.postfix.org/TLS_README.html Would be great to have this choice too.
Author
Owner

@lukas2511 commented on GitHub (May 26, 2016):

This is now implemented in ec48906992. See https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/per-certificate-config.md for more information

@lukas2511 commented on GitHub (May 26, 2016): This is now implemented in ec48906992ca9e1238dbcc9659e576cdd6bbeb07. See https://github.com/lukas2511/letsencrypt.sh/blob/master/docs/per-certificate-config.md for more information
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#40