Hi,
I noticed by accident that HTTP authentication seems to be quite happy about following a 302 redirect into a completely different server/domain. Is this intentional?
I didn’t even think about that, but that happened for me as well: Using webroot authentication, and getting a certificate for both www.example.com and example.com, my web server is configured to provide a 301 redirect of www.example.com => example.com, which didn’t provoke even so much as a “by the way, something hinky might be happening” message in the issuance process. (Well, I suppose these aren’t completely different domains, and they are on the same server, but I suspect it’s not being that picky at all and simply accepting 30x redirects.)
On the one hand, if a domain redirects to another domain/server that you control, don’t you in effect control the original as well? So I don’t really see this as a big deal. On the other hand, from a perspective of strict paranoia, perhaps it should only accept authentication responses from the actual domain being issued a certificate…
Yep, this is intentional. As @Kromey says: the choice to make a redirect is in the hands of the person who controls the original domain. This also makes it somewhat easier for hosting providers to help prospective customers get certificates on the hosting provider beforehand.
I guess what irks me the most is that a wrong redirect (say, a typo in the configuration) is much, much easier to set up than giving out upload rights for your server. But as long as people have thought of this and accepted it, I guess it’s fine.
this is good to know that this is a fact because some of the domains I will be trying have a force-HTTPS active, so this would be some annoying config rewrite…
by the way when the webroot redirects to HTTPS, are validity checks performed?
primarily I am using CACert ( cacert.org ) certs for the other domain (startssl doesnt do .tk) and they are not really trusted anywhere.