One of my colleagues recently pointed out a potential interaction between HTTPS RRs (RFC 9460) as it relates to ACME and HTTP-01 DV. If a hostname get an HTTPS RR into DNS prior to getting a cert validated, then there would be a problem if the ACME client resolved the HTTPS RR and auto-upgraded the http:// URI to https as part of HTTP-01 DV. Since a cert won't exist yet this would fail.
How would we want to clarify this? It's probably too big for an errata for RFC 8555 but annoying to have to have a draft just to clarify all on its own. If there are plans to do an rfc8555bis (or anything else Updating rfc8555 for HTTP-01) this could be good to include in there. The reading of RFC 8555 section 8.3 is fairly clear that: Dereference the URL using an HTTP GET request. This request MUST be sent to TCP port 80 on the HTTP server [...] > Because many web servers allocate a default HTTPS virtual host to a > particular low-privilege > tenant user in a subtle and non-intuitive manner, the challenge must be > completed over HTTP, not HTTPS > but there's a potential that implementors of HTTP client libraries implementing RFC 9460 might follow section 9.5 ( https://www.rfc-editor.org/rfc/rfc9460.html#name-http-strict-transport-secur) and get into trouble. That section specifies: An HTTPS RR directs the client to communicate with this host only over a secure transport, similar to HSTS [HSTS]. Prior to making an "http" scheme request, the client SHOULD perform a lookup to determine if any HTTPS RRs exist for that origin. To do so, the client SHOULD construct a corresponding "https" URL as follows: 1. Replace the "http" scheme with "https". 2. If the "http" URL explicitly specifies port 80, specify port 443. 3. Do not alter any other aspect of the URL. I think one potential clarification to RFC 8555 Section 8.3 would be that validating clients SHOULD NOT do a resolution of HTTPS RRs. Best, Erik
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
