Symbolic Domain Links

Feature Requests
1

Hello,

just a tiny feature request: I'd love to see certbot creating symbolic links for all "-d" domains (which are specified by the "-d" parameter).

The reason is that any software would find all additional domains in "/etc/letsencrypt/live/" as symlinks to the default domain created by certbot. As I've implemented a small "SNI"-extension in/for Node.js which dynamically looks up the TLS domains directly in the file system, it would really be great if the SNICallback could find all of these extra domains there, too!

At the moment I've just created a script which automatically creates these symbolic links, but it would be great if certbot could do this automatically (or with another argv-switch).

See also < https://libjs.de/examples/net/sni.js >.

Greets from Germany; Sebastian. :slight_smile:

1 Like
2

What does your script do (and what would you hope certbot would do) when it encounters a certificate that contains a SAN you've already created a symbolic link for from another certificate?

For example:

Cert1:

  • svc1.example.com
  • example.com
  • www.example.com

Cert2:

  • svc2.example.com
  • example.com
  • www.example.com
3 Likes
3

There seem to be only two choices:

  • fail to create a link when a matching link already exists
  • replace all previous links

neither of which may be 100% correct; as shown by your example (@rmbolger): Only one link can be used but there are more than one path to link them to.
If you choose first come, then Cert1 wins and the link will point there.
If you choose to replace, then Cert2 wins and the link will point there (after overwriting Cert1 link).

[yes, I have been know to state the obvious]

1 Like
4

Indeed. I was just trying to think of potential complications with the idea that would need to be addressed.

2 Likes
5

While by default the name of those directories is indeed one of the hostnames contained in the certificate, this is not necessarily the case. With --cert-name one can easily choose a certificate name NOT being one of the hostnames. Therefore, to me, it doesn't make sense to assume the directories in /live/ are hostnames to begin with. That this by default is the case, doesn't mean it's always.

I would urge you to re-think your script which automatically creates those symbolic links, as this is highly "out of spec".

2 Likes
6

Thanks for your replies!

I also already figured out the problem with multiple use of domains in different certs etc. ... if we really tried to do it that way, there could be a command or switch to list domains and select the one we wanted.. alternatively, I would always prefer the newest cert/key. But ...

Hm, but OK, your objections are good. Can you tell me another way to "index" all the avaiable/used domain names, or where can I find these..!?

My problem is, that I don't (ever) want to specify every additional domain every time by myself/hand.
Instead, I need to access some kind of list of possible domains, with the paths to key/cert, so everything could work absolutely automatically... is this a problem?

LG.

1 Like
7

The command certbot certificates lists the certificate name and the hostnames included in the cert.

At the moment, this output is "human readable" only unfortunately, but I've already developed an CLI option which switches the output to JSON, so it can be parsed by scripts more easily.

3 Likes
8

You can use --manual-cleanup-hook and access CERTBOT_ALL_DOMAINS when CERTBOT_REMAINING_CHALLENGES is 0, and set up symlinks or whatever you want to happen to make your environment work the way you want manually. Most recent certificate wins is certainly a workable policy.

2 Likes
9

Hm, I rather hoped there could be a way to only use the file system for this reason.
Starting an extra process could be a little slower than accessing the file system?

But OK, this is nevertheless a good solution, also your JSON output. THANK YOU! :slight_smile:

2 Likes
10

There's nothing that would prevent you from building your own system with symbolic links et cetera. But heed the warnings of @rmbolger and @rg305 with that approach. I'm just warning you that the /live/ directory probably isn't the correct place to do that.

5 Likes
11

I tend to disagree here:
If more than one active cert contain the same FQDN(s), then both are equally valid.

Although one could argue that if only that FQDN is being used by the link, then either would work.
But it really depends on the objective (initial problem these multiple links are supposed to resolve).
[which hasn't been made all that clear to me (yet)]

1 Like
12

This could also be useful for variable support in nginx >= 1.15.9 as in:

ssl_certificate /path/to/$ssl_server_name.crt;

I think this is perfectly possible to do today using a --deploy-hook, provided that it is driven by something that is constrained in the appropriate ways (e.g. no overlapping names).

As a feature request, I think it's probably too exotic to be included natively in Certbot.

2 Likes
13

Is that any better than just using a customer #?
set %customer-var% 'customer-XYZ1234'
certbot --cert-name %customer-var% -d some.unique.domains
ssl_certificate /path/to/%customer-var%.crt;

1 Like
14

Well, the one use case I have in mind is a SaaS situation where you avoid duplicative vhosts for each of your customers. So you would only have one HTTPS vhost full stop:

server {
  listen 443 ssl;
  ssl_certificate /opt/app/certs/$ssl_server_name.crt;
  ssl_certificate_key /opt/app/certs/$ssl_server_name.key;
  location / {
     proxy_pass http://backend;
  }
}

That allows the nginx configuration to stay small and static, and the only moving parts are the certificates on disk.

I guess you could do something similar via map $ssl_server_name $customer_id { ... }. That'd be only slightly more complex.

1 Like
15

Heyho,

my problem is, that the domains are totally unknown, I can't even assign/map them to some variable (like your %customer-var%). OK, sure it'd possible using some functions like "registerCustomerDomain" etc., but this requires to prepare everything with even more information I don't have - .. where I just want to compare the addressed TLS domain against a list of all available ones... you understand?

But ... now I think (beneath my own script) about starting the certbot certificates process (with JSON) on instanciating my TLS-SNI helper class, to cache the results then. Even if this is really SUB optimal (for me).

My 2nd thought is: also using a script to be called after any certbot activity, which gets the JSON output of the certificates list, and then creates my "beloved" filesystem index structure somewhere else.

But agian, thanks for your replies.

1 Like
16

Have you heard of Caddy?

2 Likes
17

Hello again,

some of you asked for my tiny script. I am using it, as I don't need any other --cert-name or so. Managing pure Domains/Hosts, so I don't need to configure any server. .. here it is:

< https://libjs.de/scripts/certbot.sh.txt >

Have fun! Cakes.

PS: I had an error in < https://libjs.de/examples/net/tls/sni.js >, now it works for me (used my own Object instead of "tls.createContext()"... ^_^).

18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.