On Wed, Sep 12, 2018 at 08:55:50AM +0000, Tobias Erichsen wrote: > Hello everyone, > > there have been various feature proposals on the Let's Encrypt community > forum and also at least one here on this mailing-list > (https://www.ietf.org/mail-archive/web/acme/current/msg00641.html) to > implement a version of the dns challenge that is > less complex than the current solution where a generic client needs to > implement a large amount of different APIs to cover > all the DNS-providers in the wild, some of which don't even provide > automatable APIs... > > I'm really curious to learn about the reasons why those proposals have been > ignored. Perhaps I overlocked some explanation, > but I did not discover any yet... > > One defined TXT-Record for each ACME-provider like Let's encrypt for example > which contain the SHA-512 hash of the publid key, > or the hash of the account-name should really suffice to prove the > domain-control when trying to renew certificates... During > the ACME renewal, a cryptographic exchange of a token should prove the > control over ACME public/private. > > Is there anything I have overlooked which would be a reason to block the > introduction of such dns-02 challenge?
Yes, you overlooked CABForum Baseline Requirements. These requirements require DNS validation to return one of: - Public key (hash) + timestamp, valid at most _30_ days. - Public key (hash) + nonce, valid _once_. - Random >=128-bit Value specified by CA, valid _once_. However, due to the fact that CNAME and NS are just magic in DNS, those are chased and as such, from point of server operator there would also be: - CNAME to target specified by CA, valid _until_ _removed_. This is implemented by at least one CA (Amazon, only issues certificates for cloudfront and such). For proposal of such mode in ACME, search the mailing list archives for "assisted-DNS". Another way as consequence of CNAME and NS records being chased is CNAME'ing the _acme-validation to another nameserver (possibly self- hosted), that does properly support automatable API. If you have a single-server setup, one can set up DNS on that server to handle validation like follows: _acme-validation.firstdomain.example CNAME bar.acme.firstdomain.example _acme-validation.foo.firstdomain.example CNAME bar.acme.firstdomain.example _acme-validation.seconddomain.example CNAME bar.acme.firstdomain.example acme.firstdomain.example NS firstdomain.example firstdomain.example A <ipv4 address> firstdomain.example AAAA <ipv6 address> Then configure a DNS authoritative for acme.firstdomain.example on the server, with API access. The validation requests for firstdomain.example, foo.firstdomain.example and seconddomain.example will be sent to that server as TXT requests for bar.acme.firstdomain.example. If you want to actually cryptographically secure the domain, then the DNS server on the server must be DNSSEC-capable, you need also DS record for acme.firstdomain.example, and also CAA validationmethods only allowing dns-01 on each domain apex, all DNSSEC-enabled. If this is not done, then the domains will be vulernable to usual DNS and routing attacks. -Ilari _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
