Able to verify, even though it redirects to a different domain

I had some problems verifying a subdomain in my multi-domain certificate, even though the same setup was working before.

So I figured out that the problem was that with subdomain all HTTP requests were redirected to HTTPS, but without the path. So http://abc.example.com/.well-known/acme-challenge/gmyRNHqHW1-8XLrabd6e8cA6521ef13iV-4jsqgtqEE was being redirected to https://abc.example.com/

So I tried to fix it by adding a rule in my NGINX configuration that would redirect all urls that start with /.well-known/acme-challenge/ to https://example.net$request_uri. This worked, but then I noticed that I accidentally used a different domain. example.net instead of example.com. So I accidentally redirected to a different domain. I own both domains, and all domains share the same acme-challenge folder, so all the files needed to verify were present on both domains.

So my question here is, isn’t this a security problem.

If I can somehow have the url /.well-known/acme-challenge/..., on a domain and server that I don’t own, redirect to my own domain and server. Could I get a certificate for a domain I don’t own?

For example some url shortening services will let you select a custom url. I for example registered tiny.cc/well-known but using tiny.cc/well-known/acme-challenge/abckjchakjhcklhwhcwkjhjk will also result in a redirect. tiny.cc doesn’t allow dots in their custom urls, but there are tons of other services that may allow it.

You need meet some very specific requirements, but I’m sure that there is a website somewhere, where this would be possible to do.

Wouldn’t it be prudent to verify that the TLD of the redirect is the same of the TLD of the domain that is being verified?

Exact matching of the entire domain would be bad, with all the www to no-www redirects (or vice-versa) that everyone is using.

Probably, but if you have enough control over that domain/server to implement that redirect, you have enough control to pass the challenges anyway. “Able to change the web server configuration” is adequate control over the hostname to demonstrate domain ownership to LE’s satisfaction.

That’s not what I was going at. Getting a url to redirect to your own server is a lot more common than being able to create files with specific names, in specific subfolders, with specific contents. I thought the tiny.cc example adequately showed how this would be possible (if they had allowed dots in the url)?

Looking a bit further, it seems the specification already acknowledges this problem.

More limited forms of delegation can also lead to an unintended party
gaining the ability to successfully complete a validation
transaction. For example, suppose an ACME server follows HTTP
redirects in HTTP validation and a web site operator provisions a
catch-all redirect rule that redirects requests for unknown resources
to a different domain. Then the target of the redirect could use
that to get a certificate through HTTP validation, since the
validation path will not be known to the primary server.

The goal of having /.well-known at all is to have a particular path that’s reserved and known to have a special meaning.

https://tools.ietf.org/html/rfc5785

If services allow untrusted people to create content or redirects involving /.well-known, they’ve violated the whole point of the existence of /.well-known. Presumably the remedy for this would be to make /.well-known more well-known. :slight_smile:

I guess your quote from the ACME specification does acknowledge a risk here, but we can also imagine cases involving hosting providers where the behavior is intended (such as having the ISP’s main domain allowed to speak for customer domains for validation purposes).

1 Like

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