Create Symlink for SANs


It would be nice, to create /etc/letsencrypt/live/SAN -> /etc/letsencrypt/live/CN symlinks for all subject alt names on the certificate.

Then the client could manage replacing a “domain a.domain” certificate by “domain a.domain b.domain” certificate when adding another subdomains to the same certificate. And installation would be easiert, because every domain has a fixed path to the .pem file, disregarding if its the CN of the certificate or a SAN.


It would be relatively easy to write a bash script to do that. Or were you meaning more as a suggestion for inclusion in the default LE script.


I do it even by hand, but i think it would be a good feature for the standard client, as it is intransparent which SAN a certificate has / on which certificate the (sub)domain is a SAN with the current implementation.

With this, you would not only find the right certificate for the (sub)domain, but even notice unwanted / superfluous SAN on any certificates you’re using.


Of course you could have a domain on two certificates, but this is the case for duplicate common names as well. So this needs some kind of conflict resolution anyway, as two certificates with the same common name and different alt names may be useful for some people.

I think currently the client just symlinks the latest certificate with the common name, which effectively hides the other certificates as well.


Personally I don’t see the benefit ( that may of course just be the way I use certificates, or just my understanding).

I tend to have one certificate per website ( so and www. … or and www. ) This means that each website points to a different certificate - so symlinks for for the other SAN’s would just be additional clutter.

I’ve never bothered to add new subdomains to an existing certificate, I just create a new certificate for that subdomain.

I’ll leave others to comment if it’s useful for them.


Maybe this would be the best solution, but the recommended way to deal with api-limits on subdomains is to use more SAN, so this seems relevant (indeed i split a lot on my main domain and needed to wait 7 days for the second list of subdomains).

I would think the www.domain -> domain symlink may be omitted, but OTOH you even have the problem with duplicate common names, as mentioned, so it should be handled in a proper way.


The recommended way isn’t to add to existing certificates though, and personally I never have the same domain on multiple certificates.

I need more than the 5 ( the limit for 7 days) however I spread them over time ( and hence spread the renewal), so I never hit the limits ( which would be 40 subdomains ) - I’d have thought that 40 subdomains was well above the amount of an average user, so that those with more than 40 subdomains I’d expect to have some technical skill to be able to deal with things.

Sorry, I’m not meaning to be negative about your idea, it just doesn’t work for me - there may be others for whom it does work.


I would still advocate for an global limit of 200 (sub)domains per 30 days instead of 5 per domain/7 days, but the official suggestion is to use more SAN.

But this is getting off topic here, the suggestion in this thread is to make better absolute paths per CN/SAN in the letsencrypt config folders. At least for unique domains (only on one live certificate) a symlink should be easy, collision handling would be a nice addon.


This is only tangentially related, but there probably won’t be a commonName field in LE certs eventually, as it’s been deprecated for over 15 years.

So which domain is ‘more canonical’ than the others would be arbitrary, like the first domain in the SAN extension.

So you basically just want to move the “domain -> cert file path” mapping out of the Apache/webserver configuration files, which IIUC is where it currently resides, and into the filesystem, as an extra layer of indirection?


It’s interesting relation is, if the order of SAN (is there a defined order?) may be needed to determine the name. Or that the cert should be stored i.e. under its serial and linked to all its SAN, as there is no canonical name.
And as said not even a canonical name -> cert mapping, as you can have several certs for one (sub)domain.