Plans for wildcard certs using HTTP validation?

As many organizations do, most of our servers are internal. (For reference, we have about 80 servers, and only 3 are public-facing.)

We are using Let’s Encrypt for our public-facing servers, and we really like it.

However, we would like to do the same with our internal servers. I know that DNS validation can be used to obtain a wildcard certificate, but the issue is that we are a state-government agency, which means that we control only our internal DNS; our public DNS is controlled by a parent state-government agency. For example, I can make sub.example.com myself, but the second I want that to propagate to the outside world, I have to put in a request to the parent agency. The parent agency will do it with no questions asked, but the issue is that it’s a manual process.

Obviously, I am not going to go through this process every 90 days to renew our Let’s Encrypt certificate.

In the future, can wildcards be validated via HTTP? When we validate a single server via HTTP validation, why is that not sufficient to validate all of its subdomains, too? To my knowledge, if you control example.com, you ultimately also control sub.example.com as well. (I understand that you can “sub-lease” subdomains to other tenants, but that’s the domain owner’s prerogative and, in my opinion, not anything Let’s Encrypt should be concerned about.)

What’s the technical or practical limitation of HTTP validation for an entire domain and its subdomains?

1 Like

point a CNAME on _acme_challenge.main.domain to some domain you control, and use dns alias mode of acme.sh for that domain.

3 Likes

That sounds interesting. Will this work if there is actually only a single domain? To be clear, we have no control of any public DNS.

you need to have api access of alias domain, and one time access for main domain to set CNAME record on acme challenge. but Alias doesn’t need to be same base domain, so buy a random cheapest domain will work.

As a state agency, we can’t legally do that. Hence why I’d like to see HTTP validation for wildcards if possible.

then I think you’re out of luck here. Allowing DNS-01 only for wildcard is policy decision of Let’s encrypt.

Yeah, but I’m curious why. If you can prove control of domain.com, don’t you implicitly control sub.domain.com?

Not always—for example, at universities there might be a web team for the top level university site but they don’t control departmental sites and services. They are also not necessarily the same people as the university-wide IT department.

1 Like

Sure, but the university ultimately still controls them, don’t they? I mean, where I work, we do that, too, but at the end of the day, we still own domain.com and its subdomains, regardless of what our internal policies are. If domain.com goes away, so does its subdomains.

I guess what I’m really trying to understand is why DNS validation is any more a predictor of domain control versus HTTP challenges of domain.com itself. By the logic of “but subdomains may be controlled by other people,” couldn’t the same be true even if using DNS validation?

1 Like

It is not unusual to put marketing department or even external entity (e.g. PR agency) in charge of company website (let's assume it's example.com and www.example.com) - while they control HTTP content for example.com, they should not be able to obtain certificate valid for any other subdomain (like vpn.example.com or mail.example.com). Ability to make changes to DNS records is considered "stronger" form of authorization - you don't delegate DNS control to other entity without a good reason (as this - technically - allows to spin up new services in given domain without asking for your authorization).

I guess I just see this differently. I would argue that you similarly don't delegate HTTP control of a domain without a good reason, as well. If you're delegating control of domain.com to a PR company, in my opinion, you assume all the risks associated with doing that. That includes someone potentially issuing certificates. If you don't like that a PR company can do that, then you shouldn't delegate control.

To me, based on what I've read so far, this seems more like an issue with Let's Encrypt at a policy level than a technical issue. It sounds like Let's Encrypt is trying to get in the minds of organizations on how they may potentially operate at a policy-level, which I would believe is out of their purview, at least from an outsider's view, since this can be drastically different from one organization to another.

Along the same lines, DNS can be delegated, as well. It could be delegated -- or sub-delegated -- to many people within an organization. Or even people outside the organization. It's just a matter of having credentials and authorization to do it. The same is true with placing a file on a server for the world to see.

As far as spinning up new services; you can do that with or without subdomains by hosting multiple sites on a single domain.

If different people control subdomains of a domain that I own, then I would think that I ultimately still have control. If I have given that control to someone else, I would think that's my problem, not a CA's problem.

I'm not trying to be difficult. I just don't see the substantial difference between showing control of domain.com -- that is, not even www.domain.com but the actual domain.com -- versus showing the same by creating a new subdomain through DNS. I mean, what if you've been delegated rights to create new subdomains but you don't have control over domain.com? Yet, if you ask for a wildcard certificate, you get it, while the folks who have the actual ability to put a file on domain.com can't ask for such a certificate?

Our university has delegated our an external web hoster that provides us with a CMS. That means they can obtain certificates for exactly the websites we've entrusted them with. Those are basically all "poster" sites.

They do not control the imap subdomain, so they can't read our mail. They do not control the intranet subdomain, so they can't read our secret procedures. Nor the human resources stuff. We like to keep it that way.

2 Likes

Not without the ability to create DNS TXT records at the apex domain. For example, at MIT, students can create subdomains of their choice under mit.edu, but they can't create arbitrary TXT records within the domain.

DNS is an ability that can be delegated. So yes, what you are saying may be true at MIT, but it's not necessarily the case everywhere. To me, it seems that Let's Encrypt is trying to predict how an organization operationally works and make policies based on that guess.

Again, I'm not trying to be difficult and what you're saying makes sense. I'm just suggesting that while it's true that someone who makes a file on the apex domain may not necessarily be in complete control over the domain as a whole, the same could potentially be true for someone who has DNS permissions. Yes, comparatively, it may be less likely, but if we're going to make guesses on the operational policies of organizations, why aren't we including more organizations? Or is that just where the line in the sand has been decided?

Unfortunately, every CA needs to do that in deciding what counts as legitimate authorization to issue a certificate—and Let's Encrypt's policies (like other CAs') have been informed by examples of what we knew that various organizations were doing. For example, the TLS-SNI-01 deprecation (a long and somewhat painful change to the methods that could be used to prove control of a domain) was entirely a result of a security researcher's observation about a practice of some commercial hosting providers that could likely lead Let's Encrypt to become confused about whether a certificate request was made by the real domain registrant or by someone else on a shared hosting platform with the domain registrant.

That deprecation happened even though Let's Encrypt broadly felt that the hosting providers' existing behavior was not a good practice, because of the realization that we couldn't change it everywhere and that we had to take responsibility for avoiding foreseeable opportunities for misissuance of certificates.

A lot of these things do have a somewhat arbitrary component because they do involve considering what some organizations are doing and then crafting uniform rules that apply to every certificate applicant. Maybe we could say that "the life of the PKI has not been logic, it has been experience".

5 Likes

I think the reason for your confusion is that in your mind, you seem to be equating ability to create and control content with the ability to control the server. When you hire an outside agency to produce your website, you don't have to delegate control of either the DNS OR the box from which that website will be served. You can, but you don't have to. If you do, you assume those risks as you say, but if you don't trust them, you wouldn't.

Think about your own situation where you say as soon as you decide to make anything public facing you have to relinquish control to the powers that be. The reality is, though that the only thing which prevents you from creating a webserver on your own, at home, with one of those subdomains, is your own sense of honour and the knowledge that you would soon be caught once it goes live. But by then, the certificate would have been issued, because as far as ACME is concerned, you have demonstrated your control of the domain you are requesting a certificate for.

Is it possible for the parent organization to delegate one or more zones to DNS servers under your control? Such as your-agency-acme.example.net or even individual _acme-challenge.www.your-agency.example.net zones?

Earlier in this thread, buying another domain was suggested, but you can do the same thing with a zone or zones under the same domain.

From what I understand, delegated DNS subdomain control requires an entry in the https://publicsuffix.org/ list to work with LE. They don’t allow private delegations, since there’s no way to verify them.

No, it’s not a problem for validation. Let’s Encrypt doesn’t check what the DNS zone cuts are. You can delegate www.example.org or _acme-challenge.www.example.org or whatever you want.

4 Likes

Maybe once CAA extension is implemented: draft-ietf-acme-caa-05

If issuewild specify:

issuewild "letsencrypt.org; validationmethods=http-01"

they may consider they have the legitimate authorization to do it? (That way, the DNS entry doesn't need to be dynamic)

3 Likes