Apparently, both Firefox and Chrome have finally added support for HTTPS DNS records, or are at least in the process of doing so (Safari has had support for years).
I'd like to ask what needs to be done to get support for this in LE. Personally, I only need support for alias mode using the http-01 method, i.e. it would be sufficient if during validation any encountered HTTPS record would be followed, ignoring any additional A/AAAA records on the same hostname.
Besides implementation, I assume there needs to be an update to the ACME RFC... or is LE's agreement with the browsers flexible enough to allow this as it is?
I don't think current baseline have any mention to use A/AAAA to lookup IP address of a domain name: I think there need to be some discussion with root programs and wait for their decision to allow this, but I'd not surprise they conclude CA must adhere to A/AAAA record.
I'm curious how this plays out. Because HTTPS records potentially complicate the question of who "controls" a particular FQDN. Consider what may become a common case for orgs who want to start using an HTTPS record to point to their CDN, but also want to continue to support clients that don't support those records yet. Their primary DNS zone might contain the following:
; Local example.com zone
; A legacy apex A record pointing to a local web server which gives HTTP 3xx responses to the CDN
@ IN A 192.0.2.1
; An HTTPS AliasMode record pointing directly to the CDN
@ IN HTTPS 0 cdn.example.org.
; WWW equivalents both pointing directly to CDN
www IN CNAME cdn.example.org.
www IN HTTPS 0 cdn.example.org.
In a properly configured environment, where the local web server is correctly redirecting to the CDN, there's no confusion. But what if the local web server is misconfigured or compromised and not sending 3xx redirects to the right place or not sending them at all?
A CA that understands and respects HTTPS records would be fine and the HTTPS record destination would effectively override the legacy A record. But a CA that does not understand HTTPS records would send apex challenges to the local web server and www challenges to the CDN.
I'd think there would have to be some sort of BR vote and mandatory timelines for all public CAs to support proper HTTPS record resolution. LE couldn't just choose to start respecting them on its own. Some might also argue that HTTPS records shouldn't even be considered for HTTP(non-S) challenges that are only sent on port 80.
I suspect in practice that ACME http-01 will just continue to use A/AAAA records, and that people wanting something more complicated (and have enough control over their DNS to have HTTPS records) would just use dns-persist-01 once that gets all the final approvals and implementations. If there were some compelling use case that led to some big providers wanting to validate using something like tls-alpn-01 but with HTTPS DNS records instead, I'm sure it'll get through the various standards bodies eventually. But someone would need to put in the effort for it, and I wouldn't bet on that being quickly. Though my guesses on such things have certainly proven wrong in the past.
This was cross-posted to the dev-security-policy mailing list. There was an answer from the community that, under the current protocol specifications and BRs, the HTTPS record cannot be used for DV via ACME HTTP-01.
As I read it, the ACME protocol would have to be changed (+ BRs be updated) for this to be possible. Also, as multiple people already stated, validating HTTP via HTTPS records goes against its intended usage, so is unlikely to find support to motivate such a protocol change.
Corey Bonnell
For ACME http-01, using HTTPS records isn't allowed.
TLS BR domain validation method 19 (ACME http-01) requires that validations are done using http-01 as defined in section 8.3 of RFC 8555 [1]. Section 8.3 says:
As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in the DNS A and AAAA records, at its discretion.
This makes it clear the IP address must be sourced from an A or AAAA record.
In addition to the above passage, section 8.3 says in the next sentence:
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.
Section 9.5 of RFC 9460 [2] states that HTTPS records are a signal to the client to only use secure transport. Using HTTPS records to complete ACME http-01 challenges would violate this, as the initial request must be performed over plaintext HTTP.
That's a shame... HTTPS records would neatly solve the apex domain problem (i.e. no support for CNAME records on apex domains). Getting a TLS certificate is the last missing step here. I'm not really convinced by the argument that an HTTPS record's purpose is to steer clients to use only HTTPS. While this is true, a CA is not a regular client. LE already follows both multiple levels of CNAMEs as well as (unencrypted) HTTP redirects. I don't see how additionally following HTTPS aliases would be less secure, but maybe I'm missing something.
I guess tls-alpn-01 would also be manageable for us, though. Do you think it would be possible to extend this challenge instead of defining a completely new one? After all, all the clients would then have to be updated, versus a simple change on the CAs' side.
I don't think different behavior depending on the CA is a problem, the people operating the servers would presumably know which features their CA supports and configure things accordingly.
But for the case where the A/AAAA records point to different servers than the HTTPS record, and both servers want to get a certificate, maybe a better solution would be to specify whether you want to take HTTPS records into account, or alternatively simply run a challenge against both HTTPS and A/AAAA, and issue a certificate when any of them succeeds?
It absolutely is though. Fundamentally, the difference between publicly trusted CAs and private CAs and the reason the CA/Browser Forum and Baseline Requirements exists is to spell out exactly how public CAs must operate. For a Domain Validated cert, everyone has to agree what constitutes "valid control" of a domain or the trust in the whole web PKI erodes.
Let's say the BRs are updated to say resolving the domain via HTTPS records must take precedence over legacy A/AAAA records if they exist. In the example I posted, if a particular CA validated a domain only against the A record, that would be considered mis-issuance of that cert. And anyone who found out could rightfully open an incident against the CA and force them to revoke the certs and fix their validation processes.
But the wording of the BRs might not end up being that strict. I'm actually surprised at how non-deterministic the BRs are for differentiating between A and AAAA records. But the rules definitely have to be updated to allow resolution via HTTPS records in some form before any CA would be allowed to do it.
For what it's worth, I personally agree with you that the spirit of why HTTPS records exist (and AliasMode in particular) is totally applicable to HTTP based domain validation. But it's going to take time and persuasive arguments from CA/B members to make that policy change happen. And considering how long it's taking the browser vendors to add support for the records at all, that might be a while. Users are going to be stuck using providers that support "CNAME flattening" and synthetic "ALIAS" records at their domain apex for a while longer I think.
A potential issue with following HTTPS records for http-01 is that certificate validation is mandatory (RFC 9460 section 9.1 paragraph 5), this would make getting an initial certificate difficult. Given the change to existing behaviour, this would require some additional DNS based signal to authorise ignoring certificates for http-01 issuance.
dns-persist-01 is likely to take longer to be approved (all currently published drafts are insecure against the ACME treat model and is currently being redesigned) although it would likely also fulfill this need.
It is the ANAME record that supposed to solve the restriction of use of the CNAME record on the apex domain. And that is valid for many other protocols then the single hyper text transfer protocol.
ANAME is not a real DNS record type. It's a provider specific implementation quirk that allows CNAME-like behavior at a domain apex, just like Cloudflare has "CNAME flattening" and Infoblox has "ALIAS" records. They're all just synthetic A/AAAA records where the provider does the FQDN lookup on the back end and returns the resulting A/AAAA answers to the client.
HTTPS (and SVCB) records are an actual DNS standard record type, RFC 9460, that all providers will eventually support.
*Edit: Upon further investigation, it does appear ANAME was a draft standard last updated in 2019. But it apparently expired.
There's SVCB (RFC 9460) (The generic version of the HTTPS record)[1] and SRV (RFC2782)[2] already although these have seen little use for HTTP and ACME's http-01 is not considered a separate service at the moment.
Used to discover DNS server information (RFC 9461) ↩︎
Used by protocols/applications like Kerberos, Minecraft (Java) and XMPP ↩︎
TLSA records already exist for that purpose (RFC6698).
The biggest issue with that is the lack of DNSSEC deployment, in order for the TLSA record to resolved and be trusted, the following need to happen:
The TLSA record needs to be added
The TLSA record needs to be in a signed zone
There needs to be a chain of secure delegations from root zone
The client needs to be using a DNSSEC validating resolver
The client needs a trusted connection to the validating resolver (e.g. loopback, TLS or HTTPS)
The validating resolver needs additional DNSSEC records which means that if it uses another resolver, that resolver needs to be DNSSEC aware.
DoT, DoH and DoQ providers are making DNSSEC more available to clients even if the client's ISP doesn't support it, however adoption by clients and domains is still quite low.
Since SC-085, CAs are required to use DNSSEC for domain validation and might currently be the strongest reason to deploy DNSSEC on a domain (in addition to CAA records).
