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
So I tried to fix it by adding a rule in my NGINX configuration that would redirect all urls that start with
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.