FEATURE REQUEST: ancestor domain authz substitution

Would it be worthwhile to submit, as a feature request, consideration of DNS authz against example.com to imply authz of all subdomains of that domain?

In other words, if I successfully do dns-01 against example.com, then a few seconds later start authz against foo.example.com, the authz object that comes back would already be valid, without need for an additional challenge execution.

Assuming clients take advantage of this and do authz on shorter domains before longer ones, this would:

  1. significantly reduce the need for clients to update DNS records
  2. eliminate a large number of challenge POSTs (and the actual challenge verifications as well) because then authz against the subdomains doesn’t require additional challenge POSTs

It would seem to be a win-win for both LE and clients.

Hi @FGasper,

There was a long thread on this exact topic recently:

I think there might even be another forum thread about this, but I didn't find it.

That’s not quite the same topic.

That thread was for a challenge against foo.bar.example.com to try example.com as well—i.e., for that one challenge to do checks against multiple domains.

What I’m suggesting here is smaller in scope since it would still be 1-domain-1-challenge; the client could just order the authz requests so as to minimize the number of challenges that need to be actioned.

The reasons given in the other thread for why LE doesn’t do “ancestor domain challenges” don’t seem to apply to this feature request.

@jsha, could you comment on this?

Re-pinging @jsha …

Just to reiterate: while the underlying principle is the same as in the former thread, this is not the same (proposed) workflow on the Boulder side. For the cost of a check to see if any parent domains have a successful DNS challenge, the ACME server can forgo all challenges for a new authz if the domain has an ancestor domain that’s passed a DNS challenge.

A point was raised previously that it’s all automated, so it shouldn’t make a difference. The reliability of the system, though, is a function of the number of steps involved; if you reduce the number of steps while holding all else equal, by definition the system has become more reliable.

It’ll also save load on the ACME server via a reduction in challenge requests.

If nothing else, I’m curious why LE has no interest in exploring this. I can certainly understand not wanting to do a challenge for each ancestor domain of a given authz domain, but if the challenge is already done, why not make the most of it?

FWIW: Jsha is out of the office for a few days

1 Like

Hi @FGasper! Thanks for checking in. My feelings about this are the same as the ones I expressed in the previous thread: This would slightly weaken our confidence that we are talking to the proper controller of a given domain name (consider delegations, for example). And I think the load decrease is not worth that tradeoff, and the convenience factor is mostly mitigated by full automation. I’m open to changing my mind on those tradeoffs, but that’s what I’m thinking right now.

Hi @Joshua! Thank you for your reply.

This has become of more interest to my team of late because we are about to introduce DNS authz support. While it’s trivial enough to create a file in an Apache docroot, publishing DNS changes, at least in our project, is far more error-prone, what with clustering and all.

I am probably missing something, but are delegations much different from HTTP redirections? If A delegates a subdomain to B, both parties can do authz on the subdomain regardless of this feature request; likewise with HTTP redirections, it would seem? From that perspective, I’m not sure where the potential lies for improper issuance.

Hello @FGasper

I think, this would be a violation of the "Principle of least privilege".

A user validates a dns-01 - challenge against "example.com". Then he may have a certificate for *.example.com and example.com.

But the company has additional servers, for example:

customers.example.com
banking.example.com
employees.example.com
press.example.com (no sensitive data)
website.example.com (no sensitive data)

The admin of website.example.com may manage all certificates for website.example.com and may change the dns-entries. But he shouldn't have the right to get a certificate for customers.example.com usw. The other internal dns-entries and servers are managed by other divisions of the company.

Actual, there is a relation:

n names : n challenges to confirm : m1 certificates

with n >= m1, n >> m1 (a certificate with a lot of domain names) or n = m1 (one name, one challenge, one certificate).

Your idea would change this into

n names : n challenges to confirm : m2 certificates

with n =< m2 or n << m2. Such a change (included dns-entries added later) would break the trust of the ACME-Protocol completely. The consequences of one confirmed challenge would be unclear - per design.

Hi @JuergenAuer,

I’m not following your terminology, but the CA Browser Forum Baseline Requirements’ definition of “Authorization Domain Name” allows for validation against a parent domain to suffice for validation against a subdomain.

(For reference: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf)

LE doesn’t accept HTTP for wildcards because it’s possible to control HTTP for parent domain legitimately without controlling a subdomain of that domain.

Control of DNS for a domain, though, implies total control over all subdomains at all depth levels, so any entity that proves control over a domain via DNS has, by definition, also demonstrated control over all subdomains of that domain.

Thus, to ask an entity that has already demonstrated control over example.com’s DNS to demonstrate control over foo.example.com is redundant.

If LE doesn’t feel it’s worth their development/maintenance effort to implement this, then OK. To say, though, that it would reduce trust when the BRs explicitly allow for it and when other CAs practice it makes me feel like there’s a misunderstanding somewhere—and if it’s mine, I want to know. :slight_smile:

Did you consider making CNAME records for the relevant _acme-challenge records? I'm sorry if you've already discussed this approach in the other thread. This approach can often provide a lot of flexibility in the DNS challenge validation strategy.

This is correct - but only at the time of the validation. Not one or two days later.

In the last years, I used Rapid-SSL-Wildcard-Certificates (last from 2016 - 2019). One Validation per Mail -> one Certificate. As customer, I would never think that a confirmation today for *.example.com allows to download a second certificate for blog.example.com three days later. Without a new validation.

Later, there came the Google-Symantec - conflict. I needed a new certificate. It was free - but a new authorization was required.

Certificates are critical. So - as customer - I think, it's better to have a 1:1 - relation between domainnames and challenges. Without impact to new orders in the future.

If

other CAs practice it

then I am not happy about that.

From the view of a developer, it would be easier to get a lot of new certificates (blog.example.com if *.example.com is confirmed) without a new authorization.

But from the view of a customer, one confirmation should not allow the download of additional certificates outside the scope of the confirmation and days later.

Did you consider making CNAME records for the relevant _acme-challenge records? I’m sorry if you’ve already discussed this approach in the other thread. This approach can often provide a lot of flexibility in the DNS challenge validation strategy.

We don’t control the actual DNS deployment; for example, an admin that uses our software can run DNS on a single machine or on a cluster, using any of several nameserver daemons. Thus, our options in this regard are limited. We could take some steps in this direction, but that would require a substantial development effort and risk conflict with whatever DNS setup a user might have anyway.

But from the view of a customer, one confirmation should not allow the download of additional certificates outside the scope of the confirmation and days later.

You’re concerned about the longevity of challenge requests? I’d be fine with having them last only for, say, an hour. But I don’t think this relates to my proposal. Your concern is just as applicable to LE’s status quo.

I don’t know how long LE honors challenge successes, but let’s say it’s 1 hour. Is there any difference in trust level if, within that hour, a CA honors a DNS challenge against example.com as valid for foo.example.com?

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