Hello everyone!
I have tried to issue a certificate with dns-1 challenge with help of acme-dns and is works as expected. I'm using kubernetes with cert-manager.
I have created this CNAME record:
_acme-challenge.example.com CNAME someletters.auth.acme-dns.io
So, I can create certificates for example.com and *.example .com but I if I want to create a certificate for www.example.com, I need to create a dedicated CNAME record for it.
My question is, if we can create a wildcard certificate with a single CNAME record for root domain, why should we create dedicated CNAME for each subdomain?
Regards
1 Like
Welcome to the community!
In the generic case, a subdomain may be delegated to a different name server, so it may belong to another administrative unit. That unit should have the option to create certificate for the domain they are in charge of.
6 Likes
The TXT record must match the FQDN.
example.com
doesn't match:
www.example.com
The first requires:
_acme-challenge.example.com
The second requires:
_acme-challenge.www.example.com
The wildcard is a special exception as it doesn't require:
_acme-challenge.*.example.com
but also uses:
_acme-challenge.example.com
6 Likes
I got your point. You mean that If I delegate a subdomain to other NS, then I cannot create CNAME for that subdomain so I cannot request for a certificate for that subdomain. Only the subdomain admin can request for certificate.
But I can generate a wildcard certificate and the wildcard certificate is also valid for the subdomain!
1 Like
Yes, you can also generate certificate for the delegated subdomain, the wildcard certificate covers it. But that is not the main point. The main point is that the delegation be able to generate certificate.
Anyhow, there could be a deep hierarchy of delegation with many levels of administrative boundaries. That is very intrinisic as the DNS is designed and implemented. Each level should be able to generate certificates for the domain it controls, independently of the other levels in the delegation hierarchy.
5 Likes
I'm not sure I answered your question previously...
So, here is another attempt at that:
Since acme-dns.io will be the one hosting the TXT records, you must provide information [via CNAME] in your DNS zone for that to happen.
You would think that you could make just one CNAME entry to cover all possible names, but you actually can't.
There is no such thing as a CNAME entry for TXT records [only].
So, since the CNAME will take complete ownership of that FQDN/entry, is why they append "_acme-challenge" to the FQDN.
- the FQDN remains in tact [IP unchanged]
- the TXT record [with the longer name] can then point to anywhere else
But that creates a situation where you can't append "_acme-challenge" to a wildcard DNS entry:
"_acme-challenge.*.example.com" is NOT allowed.
[even where *.example.com is allowed (in DNS)]
So, the wildcard entry is the exception to the rule.
If you can cover all your FQDNs with a wildcard cert, then great, you can use one CNAME to delegate it. But if you require sub-sub domains, then that wildcard cert won't cover them, nor will the CNAME entry in DNS.
You would have to make a CNAME entry for each sub-domain OR FQDN.
Example:
www.dev.example.com[not covered by either CNAME previously created]
requires CNAME for either:
_acme-challenge.www.dev.example.com
OR
_acme-challenge.dev.example.com[if covering it with a wildcard certificate]
5 Likes
I don't recall anything in the ACME Spec or CA/B Forum Baseline requirements that prohibits this. I think the requirement to create a separate authorization/challenge stems from the workload and resource allocation that would be required to handle this.
LetsEncrypt caches successful validation challenges for up to 30 days, because the CA/B forum rules allow it - and doing so optimizes enough of the normal server load. This caching isn't guaranteed and could go away at any time.
Having a *.example.com wildcard does imply the account-holder has enough control of the domain to generate a specific FQDN certificate that matches the wildcard, but would require a chunk of code to look up the validity of the account to issue that certificate.
Authorization/Challenges are relatively short-lived, so I don't believe the existing * challenge could be re-used by the account for a specific wildcard and be in compliance with the rules (though caching fora short time is allowed). There does not exist an ACME command to issue specific FQDN certificates based on a wildcard pattern challenge, and I think adding one would require a formal spec with CA/B approval.
It would also require some amount of assurance to end-users of the validity for a challenge , which I don't think the ISRG team is in position to do. I think if ISRG had the resources to explore this, launching such a feature would probably need the backing of the CA/B forum, if not in an accepted rule explicitly allowing this, then at least having a few of their members chime in and say this is definitely allowed and does not pose any overt security risks.
So, IMHO, it basically comes down to a mixture of infrastructure/resources and bureaucracy.
(I am not an employee of ISRG or any CA/B member, this is just my understanding).
4 Likes
Thank you @rg305 for explanation.
You are right, the limitation on defining a _acme-challenge.*.example.com record maybe the case.
You have explained the workflow of actual procedure to request a certificate, but still this question is not answered:
If I can request a wildcard certificate for my domain, then it shows I'm eligible to request a certificate for a defined subdomain. So only defining "_acme-challenge.example.com" should be sufficient for requesting certificate for subdomain and wildcard. What is the benefit of defining dedicated CNAME record for each subdomain?
1 Like
Good point!
So, I think you believe defining a separated CNAME for each subdomain is pointless too and it is actually a workaround based on existing procedures.
I'm thinking same as you, but I was afraid maybe there is a reason behind it that I'm not aware of it!
I’d call it “potentially pointless”.
There are a few ways this could be implemented, including (but not limited to):
- use a new wildcard entry for any subdomain
- use a cached wildcard authorization for any subdomain
None are explicitly supported in the RFCs or CA/B baseline agreement - though I don’t see any reason why it couldn’t potentially be supported in the future, as there doesn’t seem to be any conflict with existing rules, and this would likely pass security reviews.
But the utility of this is pretty limited, so I don’t think we’re going to see much motivation to extend ACME to support it. such a feature isn’t going to used by many users, and the users who could utilize it aren’t going to consume significantly less resources with it enabled, so I can see it just getting pushed further back on every task (re)priortization session. It seems more like a “maybe One day” ticket in a product roadmap.
4 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.