Closed bengerman13 closed 5 years ago
siennathesane
commented
5 years ago In the new version of the let's encrypt library we need to update to, we'll have to implement an entire DNS provider interface for non-trivial effort if we opt out of HTTP-01. Can you paste your findings here?
bengerman13
commented
5 years ago This was when staging-182285.cdn-broker-test.cloud.gov was CNAMEd (DNS CNAME) to a CloudFront distribution that did not have it as a CNAME (CloudFront CNAME, that is)
curl -k staging-18285.cdn-broker-test.cloud.gov
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML><HEAD><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>ERROR: The request could not be satisfied</TITLE>
</HEAD><BODY>
<H1>403 ERROR</H1>
<H2>The request could not be satisfied.</H2>
<HR noshade size="1px">
Bad request.
<BR clear="all">
<HR noshade size="1px">
<PRE>
Generated by cloudfront (CloudFront)
Request ID: -tPXVcZvPpgz5nsY6h9HF-xNMwLIC33-M3BfaKd9AG1RSvoljp-bNA==
</PRE>
<ADDRESS>
</ADDRESS>
</BODY></HTML>Logs from the CDN broker show the same thing. To elaborate a little more, I don't believe HTTP-01 is possible with CloudFront any longer. If you send a request to a CloudFront distribution with a Host header that does not match one of the CloudFront CNAMEs or the default distribution name, CloudFront responds with a 403. This means that using an HTTP-01 challenge won't work, because when LetsEncrypt sends any request to the distribution, it gets a 403 rather than the text it's looking for.
siennathesane
commented
5 years ago Currently the CDN broker leverages version 1 of the Let's Encrypt API and a community library, which means there's much more control over the challenges that go back and forth. However, it's exceedingly out of date and by moving it forward to keep it sustainable, we have significantly less control over the challenges. As part of moving the library forward, we will be moving to the version 2 of the Let's Encrypt API, which operates similarly but is more formalized as a standard. As part of the library and API move, making DNS-01 challenges is much harder and the library we're using actually provides cloud-specific DNS integrations to make that process much easier. HTTP-01 challenges are substantially simpler because the broker can handle the verification process without any user intervention at all, so removing them in favour of only DNS-01 challenges doesn't seem like a good idea.
However, in version 2 of the LE API, there's formal support for wildcard certificates, which means that customers can have *.agency.gov, and not have to worry about subdomains. So it's likely a much better path to go through and split out the certificate logic into a certificate broker, and then if a customer wants to use a CDN with HTTPS, they can either supply their own certificate or leverage the certificate broker to give them a wildcard one for their DNS.
So for now, if it solves the problem, I guess disabling the HTTP-01 acceptance tests is fine, but we need to figure out how to solve the problem because DNS-01 will not alway be an option for customers.
bengerman13
commented
5 years ago I agree that continued support of HTTP-01 is a good thing to have. However, given the changes to CloudFront, the only way I can imagine continuing to support HTTP-01 is by having the user direct their DNS somewhere different, such as an s3 website or a staticfile instance until we get validation, then having them update it to point to cloudfront later. For users who are creating a whole new site, this is a little bit of an annoyance. For users who are migrating an existing site, though, this means at least half an hour of downtime.
More fallout from CloudFront changing their API. HTTP01 tests no longer work because CloudFront responds to all requests with mismatched Host headers by sending a 403.
This only tears out the test so we can ship what we have - there's still work to be done to update docs and cli output to make it clear we don't support HTTP01