I was just able to issue a certificate for a domain that is not actually pointing to my server and that I have no control over, just because there is a 301 redirect configured to a site on my server.
I get that 301 redirects are followed for subdomains of the same actual domain (mainly because often non-www domains redirect to their www equivalent), although I’d rather have admins configure their web servers correctly and excluding .well-known/acme-challenge from a redirect, but I think following cross domain 301 redirects should strictly be prohibited for obvious reasons.
Can you explain the obvious reasons? This practice isn’t forbidden by the baseline requirements, or any of the root programs. Some large providers also use this behaviour within their ACME integration.
The redirect is a delegation of domain control the same as having a CNAME in your DNS zone. Let’s Encrypt issues domain validated certificates and in this case you are the delegated party with control of the domain.
There are valid use cases for this. For example, I have three web servers behind a TCP load balancer, so any HTTP(S) request might be served by any one of them. To support the HTTP-01 challenge, my ACME client uploads the challenge file to a Google Cloud Storage bucket. Then I have Nginx configured to redirect /.well-known/acme-challenge/* to https://storage.googleapis.com/bucketname/*
There are other ways to do this of course. I could have Nginx proxy the request instead of 301 it, or I could have the web server fetch the file from the cloud storage bucket and serve it, etc. But this was the most straightforward solution for the environment.
For simpler setups there are still valid use cases. Suppose you want to redirect businessname.net to businessname.com. You can just set up the redirect for the whole domain without having to carve out an exception for the acme-challenge directory.
This would break existing set ups. I don’t think it should happen outside a major ACME version bump, unless some major, widespread vulnerability is found (i.e. what happened with TLS-SNI-01)
I think it is explicitly not the same as a CNAME record since I decidedly do not give away control over the domain, but instead do a redirect to another domain.
After all, my domain will not be seen in the URL when the request is finished loading. The target might control what is seen there, but it’s still another domain. Therefore the validation process never validated control of my domain, but over the content of another one instead.
Imagine a company shutting down their services and redirecting their website with a private login to another one. Would you try logging in with your original credentials on the other site of another company with another domain name? Probably not. But on the same domain name with a valid certificate? That’s a valid scenario for a nice spoofing attack.
With all the effort that is put into the issuance policies of SSL CAs I don’t see why this should be allowed.
That might have been your intention but it doesn’t match up to the semantics of domain validation under the guidelines of the baseline requirements. You delegated control to a third party of what is returned to HTTP GET requests to your domain and that’s a valid way for the third party to demonstrate control of the domain.
In the near future when remaining policy issues are addressed you’ll be able to use ACME-CAA to add a CAA policy in your domain’s DNS zone to explicitly only allow TLS-ALPN-01 or DNS-01 challenges for authorizing issuance for your domain, not HTTP-01. That would allow you to continue to redirect your domain without allowing the third party to issue a certificate for your domain.
No. I control what is returned to an HTTP GET request to my domain; a 301 redirect to another domain.
And then another HTTP GET request to another domain follows that returns the content of that domain’s website.
This is not the same.