mirror of
https://github.com/dehydrated-io/dehydrated.git
synced 2026-01-12 06:40:35 +01:00
Avoid the * wildcard in certificate directory names
#285
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @lukas2511 on GitHub (Feb 19, 2018).
Currently certificates which have a wildcard domains as CN and no defined alias will be stored in
*.example.comdirectories.This should work fine under any *nix system, but might be error-prone when used by hook-scripts or especially when typed on the shell (imagine something like
rm -r certs/*.example.com, which will erase all certificates for example.com-subdomains, not just the wildcard certificate).A solution I have in mind would be to store
*.example.comaswildcard_example.com. Since_is not part of a valid hostname this should not conflict with any possible domain.An alternative would be to just fail and ask the user to set an alias for the certificate. This would have the added benefit of having a possible way about warning users not to over-use wildcard certificates and they'd know exactly where their new certificates would be stored.
@davidolrik commented on GitHub (Feb 19, 2018):
I vote for failing if no alias is defined.
@bviktor commented on GitHub (Feb 20, 2018):
I vote for
star_example.combecause the previous convention I've seen so far has been to usestarin place of wildcard.@bviktor commented on GitHub (Feb 21, 2018):
Come to think of it, maybe davidolrik's way is the least confusing, so +1 for that, no wildcard if no alias, with a big fat error explaining the cause.
@bviktor commented on GitHub (Feb 21, 2018):
How do other clients handle this? I'd be neat to agree upon a semi-standard for this.
@LwsBtlr commented on GitHub (Feb 21, 2018):
Failing without an alias seems the right decision, as long as there is a clear error along the line of "wildcard domains must have an alias defined ..." followed by a wildcard example.com with an alias
@lukas2511 commented on GitHub (Feb 22, 2018):
I'd love to know how certbot is going to tackle this... The original naming scheme was basically copied from certbot and it would be great to keep some "compatibility" if their solution seems nice. Does anybody know something about that?
Otherwise I think I'll just be going with the alias-route.
I'll decide in the following days when I have time to continue working on the changes for the next release.
@jangrewe commented on GitHub (Feb 26, 2018):
Why not use
wildcard.example.com? Technicallyasterisk.example.comwould be more correct thenstar.example.com, but i can see that both names are more likely to be used in the wild than somebody actually having the hostnamewildcard.example.com;-)If you think that's too risky,
wildcard_example.comwould get my vote. Drölf times more thanstar_example.com, at least. ;-)What about "forcing" the apex as the alias, if none is defined, and then using the apex as the identifier? If somebody wants to have a dedicated, separate cert for the apex, they'd only need to define an alias for the wildcard domain - even if it's just
wildcard.example.com...@vaminakov commented on GitHub (Feb 27, 2018):
I vote for wildcard_example.com. Seems be best solution.
@bmw commented on GitHub (Mar 1, 2018):
Our plan for Certbot is to remove the leading
*.so if you the first domain you provide to Certbot is*.example.org, the name of the files and directories we create by default will beexample.org.@lukas2511 commented on GitHub (Mar 2, 2018):
@bmw mhm... i don't like that. for most of my own use-cases i'd like to have separate certificates for the subdomains and the main domain, so having it remap on the main domain will be a conflict... but thanks for the insight.
I'll go with the alias, easiest solution ¯\(ツ)/¯
@Eihrister commented on GitHub (Apr 16, 2018):
I hate to reopen this, but I'm actually running into an issue because of this. I do not have the option for adding example.com as an alias for *.example.com, because we are blocking non-wildcard issuance at the apex of the domain (since our customers have their own hostnames as example.com, and we want to avoid adding hundreds of thousands of CAA-records).
Our only other option seems to be (if we want to keep using dehydrated for this) is to use another name that will either not be used, or be duplicate because it's already matched by *.example.com. I do believe that certbot's way of doing this is better (since validation is also done at the same _acme-challenge.example.com). But perhaps make it optional, with default of requiring the alias, and certbot's behaviour otherwise? We have to strip *. for the wildcard anyway (hook script, for example).
@jobe1986 commented on GitHub (Apr 16, 2018):
If your certificate only contains a wild card name such as "*.example.com" you can have it place the certificates in a directory called "wild.example.com" by specifying the certificate in domains.txt like this:
*.example.com > wild.example.com