Multiple algorithms for single sets of domains (by default) #300

New Issue

adam · 2025-12-29T01:21:27+01:00

adam commented

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

Originally created by @lukas2511 on GitHub (Mar 12, 2018).

It would be great if dehydrated would (ideally by default) allow for a multi-cert configuration with RSA and elliptic curves like suggested in the Let's Encryption Integration Guide. This would allow for modern and fast cryptography with a fallback for older clients.

This would basically affect the sign_domain and command_sign_domain functions, a few filenames would change but backwards compatibility will be a priority.

I think the ideal output would be a directory structure like this:

certs/example.com/cert.rsa.pem -> cert-1234.rsa.pem
certs/example.com/fullchain.rsa.pem -> fullchain-1234.rsa.pem
...
certs/example.com/cert.secp384r1.pem -> cert-1234.secp384r1.pem
certs/example.com/fullchain.secp384r1.pem -> fullchain-1234.secp384r1.pem
...
certs/example.com/cert.pem -> cert-1234.rsa.pem
certs/example.com/fullchain.pem -> fullchain-1234.rsa.pem

I'm thinking about having the config look something like this: KEY_ALGO="rsa secp384r1"

The main symlinks like fullchain.pem would point to the first given algorithm, which will make the new scheme fully compatible with the old one (where only one was set, default being "rsa").

The certificates will be generated fully independent of each other, but double-authorization of domains shouldn't be required as the authorizations are "cached" by the CA, so this wouldn't really make the script much slower and for bigger setups there always will be the option to just choose an algorithm by setting the config variable.

Originally created by @lukas2511 on GitHub (Mar 12, 2018). It would be great if dehydrated would (ideally by default) allow for a multi-cert configuration with RSA and elliptic curves like suggested in the [Let's Encryption Integration Guide](https://letsencrypt.org/docs/integration-guide/). This would allow for modern and fast cryptography with a fallback for older clients. This would basically affect the `sign_domain` and `command_sign_domain` functions, a few filenames would change but backwards compatibility will be a priority. I think the ideal output would be a directory structure like this: ``` certs/example.com/cert.rsa.pem -> cert-1234.rsa.pem certs/example.com/fullchain.rsa.pem -> fullchain-1234.rsa.pem ... certs/example.com/cert.secp384r1.pem -> cert-1234.secp384r1.pem certs/example.com/fullchain.secp384r1.pem -> fullchain-1234.secp384r1.pem ... certs/example.com/cert.pem -> cert-1234.rsa.pem certs/example.com/fullchain.pem -> fullchain-1234.rsa.pem ``` I'm thinking about having the config look something like this: `KEY_ALGO="rsa secp384r1"` The main symlinks like `fullchain.pem` would point to the first given algorithm, which will make the new scheme fully compatible with the old one (where only one was set, default being "rsa"). The certificates will be generated fully independent of each other, but double-authorization of domains shouldn't be required as the authorizations are "cached" by the CA, so this wouldn't really make the script much slower and for bigger setups there always will be the option to just choose an algorithm by setting the config variable.

adam commented

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

@darix commented on GitHub (Mar 12, 2018):

+1 :D

I already checked the docs. nginx and apache can do it. I will find out if haproxy can do it soon.

@darix commented on GitHub (Mar 12, 2018): +1 :D I already checked the docs. nginx and apache can do it. I will find out if haproxy can do it soon.

adam commented

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

@NotActuallyTerry commented on GitHub (Mar 14, 2018):

Haproxy can do it perfectly, provided:

The files are processed as before ($FULLCHAINFILE & $KEYFILE are combined into one .pem),
The resulting files are named as example.com.pem.rsa example.com.pem.ecdsa

I currently have a setup like this running by using two configs sharing the same account. Such an option would prove rather useful.

@NotActuallyTerry commented on GitHub (Mar 14, 2018): Haproxy can do it perfectly, provided: 1. The files are processed as before ($FULLCHAINFILE & $KEYFILE are combined into one .pem), 2. The resulting files are named as `example.com.pem.rsa example.com.pem.ecdsa` I currently have a setup like this running by using two configs sharing the same account. Such an option would prove rather useful.

adam commented

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

@lukas2511 commented on GitHub (Mar 14, 2018):

@twrist great to hear that people are actually using setups like this. does haproxy really need those file-endings or are they configurable?

@lukas2511 commented on GitHub (Mar 14, 2018): @twrist great to hear that people are actually using setups like this. does haproxy really need those file-endings or are they configurable?

adam commented

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

@NotActuallyTerry commented on GitHub (Mar 17, 2018):

For doing bundling, the file endings are required and cannot be configured to be different. However, if a setup only uses an RSA/ECDSA certificate it doesn't require the extension.

The config manual explains how it works towards the lower half of the relevant section.

@NotActuallyTerry commented on GitHub (Mar 17, 2018): For doing bundling, the file endings are required and cannot be configured to be different. However, if a setup only uses an RSA/ECDSA certificate it doesn't require the extension. The config manual explains how it works towards the lower half of [the relevant section](http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#5.1-crt).

adam commented

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

@alainwolf commented on GitHub (Mar 17, 2018):

Nginx can do it, but you can't use it with "ssl_stapling_file". As Nginx allows multiple "ssl_certificate" statements but only allows one stapling file.

@alainwolf commented on GitHub (Mar 17, 2018): Nginx can do it, but you can't use it with "`ssl_stapling_file`". As Nginx allows multiple "`ssl_certificate`" statements but only allows one stapling file.

adam commented

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

@martin21 commented on GitHub (Apr 2, 2018):

Postfix can do it as well. I intend to use it with Postfix and look forward to this feature.

@martin21 commented on GitHub (Apr 2, 2018): Postfix can do it as well. I intend to use it with Postfix and look forward to this feature.

adam commented

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

@xpand-it commented on GitHub (Dec 10, 2018):

+1 I'd like to use this feature as well. Would be great to have it. Thanks for your work @lukas2511

@xpand-it commented on GitHub (Dec 10, 2018): +1 I'd like to use this feature as well. Would be great to have it. Thanks for your work @lukas2511

adam commented

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

@mark9064 commented on GitHub (Dec 25, 2018):

would love to see this as well +1

@mark9064 commented on GitHub (Dec 25, 2018): would love to see this as well +1

adam commented

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

@fei0316 commented on GitHub (Mar 21, 2019):

+1 would love to see that happening. Though ECDSA is quite ubiquitous nowadays, it's always nice to support RSA as well.
As a side question, what would be an appropriate way to implement multiple algorithms for the one set of domains now?

@fei0316 commented on GitHub (Mar 21, 2019): +1 would love to see that happening. Though ECDSA is quite ubiquitous nowadays, it's always nice to support RSA as well. As a side question, what would be an appropriate way to implement multiple algorithms for the one set of domains now?

adam commented

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

@ghost commented on GitHub (Sep 5, 2019):

This would be especially useful for public mail servers, as modern clients could benefit from ECDSA performance, while legacy ones will still be able to use RSA and won't fall back to plaintext.

@ghost commented on GitHub (Sep 5, 2019): This would be especially useful for public mail servers, as modern clients could benefit from ECDSA performance, while legacy ones will still be able to use RSA and won't fall back to plaintext.

adam commented

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

@nicoduck commented on GitHub (May 15, 2024):

Any update on that? I'm trying to figure out the least-painful way to get ECDSA and RSA certs into postfix.

@nicoduck commented on GitHub (May 15, 2024): Any update on that? I'm trying to figure out the least-painful way to get ECDSA and RSA certs into postfix.

adam commented

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

@darix commented on GitHub (May 15, 2024):

well the manual way already works

https://nordisch.org/posts/advanced-dehydration/

this issue is about doing it automatically.

@darix commented on GitHub (May 15, 2024): well the manual way already works https://nordisch.org/posts/advanced-dehydration/ this issue is about doing it automatically.

adam commented

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

@saz commented on GitHub (May 15, 2024):

I'm using a simple wrapper script:

/usr/local/bin/dehydrated:

#!/bin/bash
for arg do
  shift
  [ "$arg" = "-a" ] && echo 'Do not set `-a`!' && exit 1
  [ "$arg" = "-o" ] && echo 'Do not set `-o`!' && exit 1
  set -- "$@" "$arg"
done

/usr/local/bin/dehydrated.upstream -a rsa -o /etc/dehydrated/certs_rsa "$@"
/usr/local/bin/dehydrated.upstream -a prime256v1 -o /etc/dehydrated/certs_ecc "$@"

The original dehydrated command is located in /usr/local/bin/dehydrated.upstream

It's still not perfect. E.g. challenge validation might fail and dehydrated might continue (depending on the options you're setting) and the second time it will try it again (as it's executed twice) and you might hit some rate limits.
But it's still easier for me to handle certificates like that.

HTH

@saz commented on GitHub (May 15, 2024): I'm using a simple wrapper script: /usr/local/bin/dehydrated: ``` #!/bin/bash for arg do shift [ "$arg" = "-a" ] && echo 'Do not set `-a`!' && exit 1 [ "$arg" = "-o" ] && echo 'Do not set `-o`!' && exit 1 set -- "$@" "$arg" done /usr/local/bin/dehydrated.upstream -a rsa -o /etc/dehydrated/certs_rsa "$@" /usr/local/bin/dehydrated.upstream -a prime256v1 -o /etc/dehydrated/certs_ecc "$@" ``` The original dehydrated command is located in `/usr/local/bin/dehydrated.upstream` It's still not perfect. E.g. challenge validation might fail and dehydrated might continue (depending on the options you're setting) and the second time it will try it again (as it's executed twice) and you might hit some rate limits. But it's still easier for me to handle certificates like that. HTH

adam commented

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

@darix commented on GitHub (May 15, 2024):

tbh the config file version which is supported by dehydrated out of the box is way less painful than that :)

@darix commented on GitHub (May 15, 2024): tbh the config file version which is supported by dehydrated out of the box is way less painful than that :)

adam commented

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

@saz commented on GitHub (May 15, 2024):

@darix can you provide more details?

@saz commented on GitHub (May 15, 2024): @darix can you provide more details?

adam commented

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

@rjhenry commented on GitHub (May 15, 2024):

Did you read the linked blog post (here? That goes into detail on how to set up multiple-algorithm certificates.

@rjhenry commented on GitHub (May 15, 2024): Did you read the linked blog post ([here](https://nordisch.org/posts/advanced-dehydration/)? That goes into detail on how to set up multiple-algorithm certificates.

adam commented

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

@saz commented on GitHub (May 15, 2024):

Yes, but I still don't understand why it's less painful. I need to add the wrapper once, add a domain to domains.txt and that's it.

The other requires a cert specific config for all domains. Looks more painful to me, but that's just my opinion on that :)

@saz commented on GitHub (May 15, 2024): Yes, but I still don't understand why it's less painful. I need to add the wrapper once, add a domain to domains.txt and that's it. The other requires a cert specific config for all domains. Looks more painful to me, but that's just my opinion on that :)

adam referenced this issue

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

[PR #300] [MERGED] examples/hook: no bashism #795

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#300