Support .example.tld shorthand syntax #21

Closed
opened 2025-12-29 00:22:21 +01:00 by adam · 8 comments
Owner

Originally created by @fbender on GitHub (Dec 16, 2015).

For both the command line and domains.txt, it would be nice to handle the very common case of singing both example.tld and www.example.tld without the need to always specify both domains. Nginx uses a syntax of .example.tld which automatically expands to example.tld and www.example.tld. Would be nice if letsencrypt.sh supports this syntax the same way.

Originally created by @fbender on GitHub (Dec 16, 2015). For both the command line and `domains.txt`, it would be nice to handle the very common case of singing both `example.tld` and `www.example.tld` without the need to always specify both domains. Nginx uses a syntax of `.example.tld` which automatically expands to `example.tld` and `www.example.tld`. Would be nice if `letsencrypt.sh` supports this syntax the same way.
adam closed this issue 2025-12-29 00:22:21 +01:00
Author
Owner

@lukas2511 commented on GitHub (Dec 16, 2015):

From nginx documentation:

A special wildcard name in the form “.example.org” can be used to match both the exact name “example.org” and the wildcard name “*.example.org”.

Since letsencrypt doesn't provide wildcard certificates (yet) i think this would be more confusing than helpful.

@lukas2511 commented on GitHub (Dec 16, 2015): From nginx documentation: `A special wildcard name in the form “.example.org” can be used to match both the exact name “example.org” and the wildcard name “*.example.org”.` Since letsencrypt doesn't provide wildcard certificates (yet) i think this would be more confusing than helpful.
Author
Owner

@fbender commented on GitHub (Dec 16, 2015):

Uh, yeah, sorry, I remembered that differently. Any other idea for a syntax similar to this that could enable that feature? Or do you prefer to not support such magic?

@fbender commented on GitHub (Dec 16, 2015): Uh, yeah, sorry, I remembered that differently. Any other idea for a syntax similar to this that could enable that feature? Or do you prefer to not support such magic?
Author
Owner

@lukas2511 commented on GitHub (Dec 16, 2015):

I think it's more confusing than helpful, only thing that might be nice would be a syntax like this:

example.org {www,wiki,docs}.example.org

But still, even though it would be useful, I think it's harder to read than just to write them all out.
And if you have too many domains for one certificate i'd suggest splitting it into multiple certificates anyway... so yea... dunno.

Edit: changed example to be more like bash syntax and not like a regex, this actually made it a lot more readable, I may actually implement this.

@lukas2511 commented on GitHub (Dec 16, 2015): I think it's more confusing than helpful, only thing that might be nice would be a syntax like this: ``` text example.org {www,wiki,docs}.example.org ``` But still, even though it would be useful, I think it's harder to read than just to write them all out. And if you have too many domains for one certificate i'd suggest splitting it into multiple certificates anyway... so yea... dunno. Edit: changed example to be more like bash syntax and not like a regex, this actually made it a lot more readable, I may actually implement this.
Author
Owner

@fbender commented on GitHub (Dec 16, 2015):

Ok. Your proposal sounds cool, though. Will reduce the possible amount of human error greatly. You can also kinda support my proposal when you take an empty field as if no subdomain was specified (i.e. (|www).example.tld == (www|).example.tld == example.tld www.example.tld).

@fbender commented on GitHub (Dec 16, 2015): Ok. Your proposal sounds cool, though. Will reduce the possible amount of human error greatly. You can also kinda support my proposal when you take an empty field as if no subdomain was specified (i.e. `(|www).example.tld == (www|).example.tld == example.tld www.example.tld`).
Author
Owner

@lukas2511 commented on GitHub (Dec 16, 2015):

I'm not sure if I want this on the first parameter since that is used as path for the certificate and may result in some problems

@lukas2511 commented on GitHub (Dec 16, 2015): I'm not sure if I want this on the first parameter since that is used as path for the certificate and may result in some problems
Author
Owner

@fbender commented on GitHub (Dec 16, 2015):

I see. Last suggestion before I'll stop annoying you ;) Either …

  • you can use the first match in the brackets as the path (so (www|).example.tld --> certs/www.example.tld/cert.crt and (|www).example.tld --> certs/example.tld/cert.crt), or
  • you can always default to the generic domain as the path if the first entry is multimatch ((stuff|mail).example.tld --> certs/example.tld/cert.crt) – this is probably the more obvious option

Does that sound like a viable option?

@fbender commented on GitHub (Dec 16, 2015): I see. Last suggestion before I'll stop annoying you ;) Either … - you can use the first match in the brackets as the path (so `(www|).example.tld --> certs/www.example.tld/cert.crt` and `(|www).example.tld --> certs/example.tld/cert.crt`), or - you can always default to the generic domain as the path if the first entry is multimatch (`(stuff|mail).example.tld --> certs/example.tld/cert.crt`) – this is probably the more obvious option Does that sound like a viable option?
Author
Owner

@lukas2511 commented on GitHub (Dec 16, 2015):

Defaulting to generic domain is a bad idea, since there could be multiple certificates with very similar domains, and that could result in a conflict.

Using the first generated value may be an option, but I'll have to see how to implement this. Parsing of domains.txt will be reimplemented at some point in time anyway because of #34.

@lukas2511 commented on GitHub (Dec 16, 2015): Defaulting to generic domain is a bad idea, since there could be multiple certificates with very similar domains, and that could result in a conflict. Using the first generated value may be an option, but I'll have to see how to implement this. Parsing of domains.txt will be reimplemented at some point in time anyway because of #34.
Author
Owner

@bviktor commented on GitHub (Feb 20, 2018):

Is this implemented now for v2? Or how does one specify wildcard cert?

@bviktor commented on GitHub (Feb 20, 2018): Is this implemented now for v2? Or how does one specify wildcard cert?
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/dehydrated#21