Hi Matthias, This is permitted. It is not permitted to point the target of the CNAME to the CA, but other than that, it’s allowed.
The more interesting example of this is Amazon Certificate Manager’s example of this, at https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html Customers create a CNAME pointing to an Amazon domain in order to authorize certificate issuance, even when they do not host their DNS with Amazon. This is an example of a borderline situation, as it would appear the CA is doing the authorization, which the BRs prohibit. However, this works today because Amazon has, for whatever reason (perhaps due to serial misissuances from their own operations), chosen DigiCert to operate a subordinate CA, with Amazon effectively acting as a Super-Root - with DigiCert issuing virtually all ACM certs. Organizational shell games aside, this particular method has been discussed for years in the CA/Browser Forum, and reflects one of the unsettled open philosophical questions: is the role of the CA that of request authorization (requiring distinct requests for every certificate/key) or domain authorization (validating domains, and allowing unlimited keys to be associated)? There are clear security benefits to being request/key oriented, but the current allowances for domain validation reuse make it clear the BRs are presently domain authorization. Under today’s model, it’s entirely opaque when a CA may be reusing a cached authorization, and despite mechanisms like CAA, there still aren’t sufficient controls for domain holders, as shown by attacks like BygoneSSL. Techniques like this may prove useful for finding the right balance to reducing, or entirely eliminating, domain validation reuse, requiring persistent validation for every issuance, but allowing the domain holder the flexibility and control to durably delegate this. Certainly, in the realm where it’s the site operator involved, and the CA is not at all involved in the chain, it’s more cut and dry: it’s presently permitted. (With a Google hat) That’s not to say there aren’t security risks involved in this space, which Google has privately flagged to CAs on the CA/B Forum members only management list to draw attention to these risks and expected mitigations in the interim, but we’re working to address these long-term. On Sun, Aug 22, 2021 at 4:41 AM 'Matthias van de Meent' via [email protected] <[email protected]> wrote: > Hi, > > Today I stumbled upon the acme.sh wiki page regarding DNS alias hismode > [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/CAErg%3DHF0N2pG7GfkemJFFXQeZuC2zVWmt0DxuXxt%2BBaO6Ctv1g%40mail.gmail.com.
