Hi, Both the IETF and LE versions of the ACME spec define a DNS validation method[1] which requires the validating party to set a TXT record for a prefixed version of the hostname the cert is being requested for.
The client constructs the validation domain name by prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name. For example, if the domain name being validated is "example.com", then the client would provision [_ acme-challenge.example.com.] I can see some discussion last December about the rationale for this approach[2], but this doesn't apply to at least one large class of users, which are services which ask their users to CNAME their custom domain over to their service. For example, a CNAME is how WordPress[3], Tumblr[4], and GitHub Pages[5] allow customers to point non-apex domains at their services. If I want blog.ericmill.com to be hosted by Tumblr, I set a CNAME record for " blog.ericmill.com" with the value "domains.tumblr.com". Many other CDNs and web services operate the same way. Since DNS specifies that a CNAME can be thought of as an alias[6], this means that a service like Tumblr is capable of setting a TXT record for domains.tumblr.com with the validation token for blog.ericmill.com. A spec-compliant DNS resolver looking for a TXT record for blog.ericmill.com should follow the CNAME alias first, and then correctly identify the TXT record for domains.tumblr.com as applying to blog.ericmill.com. However, the current ACME spec asks for the record to be set for a prefix, not for the requested FQDN. And if I CNAME blog.ericmill.com over to Tumblr, Tumblr does not have the ability to set any records for a prefix, such as _acme-challenge.blog.ericmill.com. This means that services which have users CNAME domains are not able to use DNS validation to obtain certificates. I think that ACME should revisit the DNS specification and avoid using a prefix for the TXT validation, to enable this use case. Also: I can't think of any changes offhand that would enable Let's Encrypt to support a use case where users set an A record to point to a third party service, such as for apex domains in the services mentioned above. But this is another important use case, especially for service providers which don't distinguish between apex and non-apex domains in their business offerings.[7] It'd be great to hear ideas for how that might be achieved. -- Eric [1] https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#dns [2] https://mailarchive.ietf.org/arch/msg/acme/gN1NxR4kmB3c9RT4ZIvZo1SBHKo [3] https://en.support.wordpress.com/map-subdomain/ [4] https://www.tumblr.com/docs/en/custom_domains [5] https://help.github.com/articles/setting-up-a-custom-domain-with-github-pages/ [6] https://tools.ietf.org/html/rfc1034#section-3.6.2 [7] Few services distinguish these. But Bitly is an interesting case where its very nature (short links) mean that their custom domains are almost exclusively SLDs that require an A record. http://support.bitly.com/knowledgebase/articles/76741-how-do-i-set-up-a-custom-short-domain- -- konklone.com | @konklone <https://twitter.com/konklone>
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
