RFE: create a symlink for each SAN #267

New Issue

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

adam commented

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

Originally created by @TobyGoodwin on GitHub (Dec 11, 2017).

First, thanks for dehydrated - we use it extensively at my company.

I have a suggestion for a feature enhancement. Suppose you have a certificate with two names in it, so domains.txt looks something like this:

first.example.com other.example.com

then your apache (nginx / whatever) configuration will look something like

ServerName other.example.com
SSLCertificateFile /var/lib/dehydrated/certs/first.example.com/fullchain.pem

So this configuration snippet has to know that first is the certificate's Common Name. This is a violation of the "separation of concerns" principle, and can actually be quite a nuisance if you want to move things around at a later date.

Idea: create a symlink for every SAN. For example

/var/lib/dehydrated/certs/other.example.com -> first.example.com

I could probably find time to implement this, if a PR were likely to be accepted :)

Originally created by @TobyGoodwin on GitHub (Dec 11, 2017). First, thanks for dehydrated - we use it extensively at my company. I have a suggestion for a feature enhancement. Suppose you have a certificate with two names in it, so `domains.txt` looks something like this: first.example.com other.example.com then your apache (nginx / whatever) configuration will look something like ServerName other.example.com SSLCertificateFile /var/lib/dehydrated/certs/first.example.com/fullchain.pem So this configuration snippet has to know that `first` is the certificate's Common Name. This is a violation of the "separation of concerns" principle, and can actually be quite a nuisance if you want to move things around at a later date. Idea: create a symlink for every SAN. For example /var/lib/dehydrated/certs/other.example.com -> first.example.com I could probably find time to implement this, if a PR were likely to be accepted :)

adam closed this issue

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

adam commented

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

@TobyGoodwin commented on GitHub (Dec 11, 2017):

Incidentally, one of my colleagues pointed out a potential problem if other.example.com already exists and is a directory (presumably from some earlier configuration): ln -s will create a link inside the directory, named other.example.com/first.example.com. So it's important to use ln -sT which turns off the normal magic behaviour when the last argument is a directory.

@TobyGoodwin commented on GitHub (Dec 11, 2017): Incidentally, one of my colleagues pointed out a potential problem if `other.example.com` already exists and is a directory (presumably from some earlier configuration): `ln -s` will create a link inside the directory, named `other.example.com/first.example.com`. So it's important to use `ln -sT` which turns off the normal magic behaviour when the last argument is a directory.

adam commented

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

@jobe1986 commented on GitHub (Dec 11, 2017):

Another potential issue may be where you have a host name that appears as a SAN on more then one separate certificate. For example the certificate I use for openldap and the certificate I use for postfix/dovecot both include the servers own host name as well as their own individual names. Therefore the servers own host name as a SAN on both certs could not be symlinked to both certs.

@jobe1986 commented on GitHub (Dec 11, 2017): Another potential issue may be where you have a host name that appears as a SAN on more then one separate certificate. For example the certificate I use for openldap and the certificate I use for postfix/dovecot both include the servers own host name as well as their own individual names. Therefore the servers own host name as a SAN on both certs could not be symlinked to both certs.

adam commented

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

@lukas2511 commented on GitHub (Dec 14, 2017):

For me it was always common practice that a virtual host in my webserver configuration mostly equals the altnames in a given certificate. I don't really see the reason behind making a big certificate to be used by multiple virtual hosts, as you said: seperation of concerns ;)

In the old times when certificates had to be registered by hand and cost a lot of money this made sense, but nowadays even for test-environments you can get a certificate with specific altnames for free in seconds.

If you really really want this I'd suggest adding a deploy_cert hook which creates the symlink. You can extract the domain names from the altnames environment variable.

Should be as easy as something like this:

deploy_cert() {
  DOMAIN="${1}"
  for altname in ${altnames}; do
    ln -sf ${CERTDIR}/${DOMAIN} ${CERTDIR}/${altname};
  done
}

@lukas2511 commented on GitHub (Dec 14, 2017): For me it was always common practice that a virtual host in my webserver configuration mostly equals the altnames in a given certificate. I don't really see the reason behind making a big certificate to be used by multiple virtual hosts, as you said: seperation of concerns ;) In the old times when certificates had to be registered by hand and cost a lot of money this made sense, but nowadays even for test-environments you can get a certificate with specific altnames for free in seconds. If you really really want this I'd suggest adding a `deploy_cert` hook which creates the symlink. You can extract the domain names from the `altnames` environment variable. Should be as easy as something like this: ``` deploy_cert() { DOMAIN="${1}" for altname in ${altnames}; do ln -sf ${CERTDIR}/${DOMAIN} ${CERTDIR}/${altname}; done } ```

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#267