Allow multiple keys/certs for a domain #224

New Issue

adam · 2025-12-29T01:19:14+01:00

adam commented

2025-12-29 01:19:14 +01:00

Originally created by @typingArtist on GitHub (Jun 3, 2017).

Using domains.txt, afaik it is not possible to create multiple keys/certs for a domain or set of domains at the same time. For example, if I want to have a RSA and a ECDSA key for a domain, I cannot use domains.txt but have to do my own scripting around.

Originally created by @typingArtist on GitHub (Jun 3, 2017). Using domains.txt, afaik it is not possible to create multiple keys/certs for a domain or set of domains at the same time. For example, if I want to have a RSA and a ECDSA key for a domain, I cannot use domains.txt but have to do my own scripting around.

adam closed this issue

2025-12-29 01:19:14 +01:00

adam commented

2025-12-29 01:19:15 +01:00

@typingArtist commented on GitHub (Jun 8, 2017):

One aspect worth discussing is what the hooks should be called with: the primary domain as now, possibly used for multiple certificates and thus likely not the best information for the hook script, or the alias name, which would change the semantics of the hook call slightly.

@typingArtist commented on GitHub (Jun 8, 2017): One aspect worth discussing is what the hooks should be called with: the primary domain as now, possibly used for multiple certificates and thus likely not the best information for the hook script, or the alias name, which would change the semantics of the hook call slightly.

adam commented

2025-12-29 01:19:16 +01:00

@lukas2511 commented on GitHub (Jul 10, 2017):

See discussion in #400.

@lukas2511 commented on GitHub (Jul 10, 2017): See discussion in #400.

adam commented

2025-12-29 01:19:17 +01:00

@typingArtist commented on GitHub (Jul 15, 2017):

Please re-open for further discussion.

I don’t understand your answer to #400. With domains.txt and domains.d/ we have everything we need for making per-domain/per-certificate configuration changes – except for the alias name feature I suggested. What’s the point in putting another configuration wrapper around that? What if I have domains that shouldn’t get a dual-key setup like the other domains, would I create another config file and another separate call to dehydrated just for these? Then, why do we have domains.d/ after all?

If I have, say, hundreds of domains and want to have dual-key/cert setups for all of them, well, it could be some work to setup the config files in config.d/. But then I’d have some scripting for creating the entries already, wouldn’t I? Or I could maintain file links for keeping common configuration specializations in one file. Why should I put a script around dehydrated if your tool can already handle an arbitrary number of individually configured domains?

Now to the implementation I offered in #400. It was thought to be fully backwards-compatible, that’s why it looks like it does. I can understand that you don’t like the way the --alias is used in domains.txt, but please suggest an alternative that suites your taste better and serves the same purpose. And please don’t close an issue just because you don’t like one aspect of the related pull request.

If I had a word on it, I’d transform domains.txt and domains.d/ into domains.yml and have all configuration options in this single file, including, of course, the alias name feature. But I think we should consider that separately.

BTW, I’d really suggest to merge at least cd03e2a8d and 3116fe0c8c as they improve the code without adding functionality. ${domain} is already given the wrong name, is it is only the primary or CN domain, and ${altnames} for all domains except the primary is also wrong as the SAN have to include the primary domain as well. And the repetitive use of ${CERTDIR}/${domain} is also worth simplification, don’t you think?

@typingArtist commented on GitHub (Jul 15, 2017): Please re-open for further discussion. I don’t understand your answer to #400. With `domains.txt` and `domains.d/` we have everything we need for making per-domain/per-certificate configuration changes – except for the alias name feature I suggested. What’s the point in putting another configuration wrapper around that? What if I have domains that shouldn’t get a dual-key setup like the other domains, would I create another config file and another separate call to `dehydrated` just for these? Then, why do we have `domains.d/` after all? If I have, say, hundreds of domains and want to have dual-key/cert setups for all of them, well, it could be some work to setup the config files in `config.d/`. But then I’d have some scripting for creating the entries already, wouldn’t I? Or I could maintain file links for keeping common configuration specializations in one file. Why should I put a script around `dehydrated` if your tool can already handle an arbitrary number of individually configured domains? Now to the implementation I offered in #400. It was thought to be fully backwards-compatible, that’s why it looks like it does. I can understand that you don’t like the way the `--alias` is used in `domains.txt`, but please suggest an alternative that suites your taste better and serves the same purpose. And please don’t close an issue just because you don’t like one aspect of the related pull request. If I had a word on it, I’d transform `domains.txt` and `domains.d/` into `domains.yml` and have all configuration options in this single file, including, of course, the alias name feature. But I think we should consider that separately. BTW, I’d really suggest to merge at least cd03e2a8d and 3116fe0c8c as they improve the code without adding functionality. `${domain}` is already given the wrong name, is it is only the primary or CN domain, and `${altnames}` for all domains except the primary is also wrong as the SAN have to include the primary domain as well. And the repetitive use of `${CERTDIR}/${domain}` is also worth simplification, don’t you think?

adam commented

2025-12-29 01:19:17 +01:00

@lukas2511 commented on GitHub (Jul 16, 2017):

@typingArtist From what I see the only need for aliases is for dual-key/cert setups, and I really think it would be the easiest way to just have two separate domains.txt files and cert directories for RSA and other keytypes. The only thing you would need to maintain in your setup would be the two domains.txt files. If you want a cert with both key types add it two both files, if you only need one just add it to the corresponding one.

Since having two keys for the same domain combination seems like an edge-case to me I don't really know if it's worth implementing this or if it's just easier to tell the two people who really need it to create two config files, maybe even add a paragraph about how easy that is to do in the documentation.

If you'd really like to see this feature I think the best way would be to have the alias as a parameter for the per-cert-config-files instead of adding it to the domains.txt file.

And sorry for closing this ticket, I just meant to move the discussion over to the other ticket, but since that is a (now rejected) pull-request you are right that this is a better place for the discussion. Not sure what exactly I was thinking when I originally did that...

@lukas2511 commented on GitHub (Jul 16, 2017): @typingArtist From what I see the only need for aliases is for dual-key/cert setups, and I really think it would be the easiest way to just have two separate domains.txt files and cert directories for RSA and other keytypes. The only thing you would need to maintain in your setup would be the two domains.txt files. If you want a cert with both key types add it two both files, if you only need one just add it to the corresponding one. Since having two keys for the same domain combination seems like an edge-case to me I don't really know if it's worth implementing this or if it's just easier to tell the two people who really need it to create two config files, maybe even add a paragraph about how easy that is to do in the documentation. If you'd really like to see this feature I think the best way would be to have the alias as a parameter for the per-cert-config-files instead of adding it to the domains.txt file. And sorry for closing this ticket, I just meant to move the discussion over to the other ticket, but since that is a (now rejected) pull-request you are right that this is a better place for the discussion. Not sure what exactly I was thinking when I originally did that...

adam commented

2025-12-29 01:19:17 +01:00

@lukas2511 commented on GitHub (Jul 16, 2017):

@typingArtist Your commit cd03e2a8d7 is now in my local staging and will be published soon (need to test it first, probably tomorrow evening or on monday).

I'm not happy with 3116fe0 since it changes the name of the altnames variable. I think altnames is a fitting name since it stands (short) for Subject-Alternative-Names, which (at least for the biggest use case - https) is mandatory to contain all domain names (Browsers completely ignore commonName in newer versions).

Changing the name of the domain variable may be considered, but I don't like to merge it with other changes in a single commit, I'll look into this after testing your other changes. If you'd like you could split those commits for me to make it a bit easier to merge (just reply with a link to your branch, no need for a pull-request, I'll merge them on console anyway).

@lukas2511 commented on GitHub (Jul 16, 2017): @typingArtist Your commit cd03e2a8d71939cf03442f3ed7c2d92b6a8f31cd is now in my local staging and will be published soon (need to test it first, probably tomorrow evening or on monday). I'm not happy with 3116fe0 since it changes the name of the `altnames` variable. I think `altnames` is a fitting name since it stands (short) for Subject-Alternative-Names, which (at least for the biggest use case - https) is mandatory to contain all domain names (Browsers completely ignore commonName in newer versions). Changing the name of the `domain` variable may be considered, but I don't like to merge it with other changes in a single commit, I'll look into this after testing your other changes. If you'd like you could split those commits for me to make it a bit easier to merge (just reply with a link to your branch, no need for a pull-request, I'll merge them on console anyway).

adam commented

2025-12-29 01:19:18 +01:00

@typingArtist commented on GitHub (Jul 19, 2017):

Thanks @lukas2511 for reconsideration.

Regarding 3116fe0: I agree. Sorry for pushing that too hard, the main change I’d like to see there is certdir be defined outside of sign_domain() and renaming domain. Let’s stay with altnames but change domain into something like cndomain because its only role is specifying the CN field. I can rebuild the commit.

I would be really happy if it was easy to specify the alias name in the certificate’s config file in domains.d/, but, well, the alias should already be the key to that config file … that’s why there is this unpleasant --alias thing in domains.txt.

How about the following syntax. The last line shows the compatibility with the current syntax.

web-rsa: example.com www.example.com
web-ecdsa: example.com www.example.com
smtp-imap: example.com imap.example.com smtp.example.com 
other.example.com www.other.example.com

Would you accept that change?

@typingArtist commented on GitHub (Jul 19, 2017): Thanks @lukas2511 for reconsideration. Regarding 3116fe0: I agree. Sorry for pushing that too hard, the main change I’d like to see there is `certdir` be defined outside of `sign_domain()` and renaming `domain`. Let’s stay with `altnames` but change `domain` into something like `cndomain` because its only role is specifying the CN field. I can rebuild the commit. I would be really happy if it was easy to specify the alias name in the certificate’s config file in `domains.d/`, but, well, the alias should already be the key to that config file … that’s why there is this unpleasant `--alias` thing in `domains.txt`. How about the following syntax. The last line shows the compatibility with the current syntax. ``` web-rsa: example.com www.example.com web-ecdsa: example.com www.example.com smtp-imap: example.com imap.example.com smtp.example.com other.example.com www.other.example.com ``` Would you accept that change?

adam commented

2025-12-29 01:19:18 +01:00

@typingArtist commented on GitHub (Jul 19, 2017):

thanks for merging cd03e2a (0be0ab0). 👍

@typingArtist commented on GitHub (Jul 19, 2017): thanks for merging cd03e2a (0be0ab0). :+1:

adam commented

2025-12-29 01:19:19 +01:00

@lukas2511 commented on GitHub (Jul 26, 2017):

I would be really happy if it was easy to specify the alias name in the certificate’s config file in domains.d/, but, well, the alias should already be the key to that config file … that’s why there is this unpleasant --alias thing in domains.txt.

@typingArtist You know the feeling when you facepalm so hard it really hurts?... I now do.

Okay then let's do it in domains.txt, but I really dislike the --alias stuff, I'd prefer something like this:

example.org www.example.org
>alias1 example.org mail.example.org
whatever.com
>alias2 example.org xmpp.example.org

Could easily be made position independent and would look a bit like an output redirect on a shell, so it should be easy to remember how to use it.

What do you think about this?

@lukas2511 commented on GitHub (Jul 26, 2017): > I would be really happy if it was easy to specify the alias name in the certificate’s config file in domains.d/, but, well, the alias should already be the key to that config file … that’s why there is this unpleasant --alias thing in domains.txt. @typingArtist You know the feeling when you facepalm so hard it really hurts?... I now do. Okay then let's do it in domains.txt, but I really dislike the --alias stuff, I'd prefer something like this: ``` example.org www.example.org >alias1 example.org mail.example.org whatever.com >alias2 example.org xmpp.example.org ``` Could easily be made position independent and would look a bit like an output redirect on a shell, so it should be easy to remember how to use it. What do you think about this?

adam commented

2025-12-29 01:19:19 +01:00

@typingArtist commented on GitHub (Jul 26, 2017):

Great idea! Do you think we should support all corner cases as well, like the following?

> alias1 example.org
example.org> alias1
example.org>alias1

@typingArtist commented on GitHub (Jul 26, 2017): Great idea! Do you think we should support all corner cases as well, like the following? ``` > alias1 example.org example.org> alias1 example.org>alias1 ```

adam commented

2025-12-29 01:19:19 +01:00

@lukas2511 commented on GitHub (Jul 27, 2017):

@typingArtist I think that shouldn't be too hard to parse, just look for the next "token" after the redirect character.

I'm going to work on this beginning of next month, I have to do some other work first... If you want you can have a go at it.

@lukas2511 commented on GitHub (Jul 27, 2017): @typingArtist I think that shouldn't be too hard to parse, just look for the next "token" after the redirect character. I'm going to work on this beginning of next month, I have to do some other work first... If you want you can have a go at it.

adam commented

2025-12-29 01:19:19 +01:00

@typingArtist commented on GitHub (Oct 8, 2017):

@lukas2511 how about allowing multiple >alias entities per line? This would allow us to make multiple certs in one line, like so

example.org example.com >example-rsa >example-ecdsa

@typingArtist commented on GitHub (Oct 8, 2017): @lukas2511 how about allowing multiple ```>alias``` entities per line? This would allow us to make multiple certs in one line, like so ``` example.org example.com >example-rsa >example-ecdsa ```

adam referenced this issue

2025-12-29 01:29:00 +01:00

[PR #224] [MERGED] Add Lighttpd example to wellknown.md #761

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#224