Hi The BRs don't explicitly specify if following CNAME is allowed or not. Since it is a standard part of DNS, I guess it is allowed. I think it is similar to how the BRs did not specify if following HTTP recirects were allowed until version 1.6.8. The question of following CNAMEs apply to all of the validation methods, not only to the DNS validation method.
In the definition of ADN, the BRs explicitly allows you to follow the CNAME first and then remove the leftmost labels. I think this is in addition to the normal way of using CNAMEs, where you would first remove the leftmost labels and then follow the CNAME. I think the arguments for or against allowing CNAME is similar to the arguments for or against allowing HTTP redirects. Redirects are allowed, and I think CNAMEs should be too. Den søn. 22. aug. 2021 kl. 10.41 skrev 'Matthias van de Meent' via [email protected] <[email protected]>: > Hi, > > Today I stumbled upon the acme.sh wiki page regarding DNS alias mode [0], > from the discussion on Hacker News [1]. > > That page details some information that i believe to be of interest. I > believe it details some practices that go against the requirements of the > DNS Change validation method (s3.2.2.4.7). > > The page shows that if you specify a CNAME record on > _acme-challenge.my-certificate-domain.example which statically points to > _acme-challenge.dynamic-domain.example, then updating only the responses of > _acme-challenge.dynamic-domain.example will be enough to get an certificate > issued to certificate-domain.example. So, without updating the ADN or > updating the DNS records directly under the ADN we have received a > certificate for this domain. > > I believe that this is problematic practice, as no control has been proven > over the Authorization Domain Name. The BR do not mention allowing > following CNAME records, but does require the following: "Confirming the > Applicant’s control over the FQDN by confirming the presence of a Random > Value or Request Token for either in a DNS CNAME, TXT or CAA record for > either 1) an Authorization Domain Name; or 2) an Authorization Domain Name > that is prefixed with a label that begins with an underscore character" > (s3.2.2.4.7). > > To me, this sounds like the CNAME record on > _acme-challenge.my-certificate-domain.example must immediately contain this > random value or request token (i.e. following the CNAME record to a third > domain for finding the Random Value or Request Token is not allowed). > > Do note that for determining the ADN following CNAME records is explicitly > allowed ("Authorization Domain Name: The Domain Name used to obtain > authorization for certificate issuance for a given FQDN. The CA may use > the FQDN returned from a DNS CNAME lookup as the FQDN for the purposes of > domain validation. [...]", s1.6.1), but no such explicit exemption to > follow CNAME records is made for the 2nd dns domain lookup option (that > includes the extra label that starts with a prefix). > > Is my understanding that this delegation method is noncompliant correct, > or does acme.sh's wiki page detail a valid and correct DNS validation flow? > > > Kind regards, > > Matthias van de Meent > > > [0] https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode > [1] https://news.ycombinator.com/item?id=28256326 > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAs3B9oj-iFuFE9zhbDZUGLNb95fTVp%2BjGDbQcKU2hWdgtdftQ%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAAs3B9oj-iFuFE9zhbDZUGLNb95fTVp%2BjGDbQcKU2hWdgtdftQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CACAF_WidY1XZS9EoSQkudJfpXM%3D%3D0nMTq6hk7BynoCzRRh8zEg%40mail.gmail.com.
