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.
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.
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?
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.
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`).
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
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?
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.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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 bothexample.tldandwww.example.tldwithout the need to always specify both domains. Nginx uses a syntax of.example.tldwhich automatically expands toexample.tldandwww.example.tld. Would be nice ifletsencrypt.shsupports this syntax the same way.@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.
@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?
@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:
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.
@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).@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
@fbender commented on GitHub (Dec 16, 2015):
I see. Last suggestion before I'll stop annoying you ;) Either …
(www|).example.tld --> certs/www.example.tld/cert.crtand(|www).example.tld --> certs/example.tld/cert.crt), or(stuff|mail).example.tld --> certs/example.tld/cert.crt) – this is probably the more obvious optionDoes that sound like a viable option?
@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.
@bviktor commented on GitHub (Feb 20, 2018):
Is this implemented now for v2? Or how does one specify wildcard cert?