Take the Publickey of the Account and build the SHA-1 of if. (Mable later SHA-256)
Create an Textrecord sha1-dns-02-acme-challenge for domain with the Base64 content of the hash. sha1-dns-02-acme-challenge.example.com. 300 IN TXT “gfj9Xq…Rg85nM”
Improvements above dns-01:
a) It allow Wildcard entries so that the user does not need to change the dns for each fqdn.
b) As long as the account key is the same the approval is the same.
This is analog to placing an html page containing an authorization token into the webserver like google use is for webmaster info access. We do not need the random factor to prevent replay. As long as we bind the authorization to the account key.
IIRC they’re in the same family and if one is broken the other is probably, too. But the challenge is currently missing a random token which is a MUST by the CA/B Forum rules.
hm, but the question is why? I mean account binding seems to be enough for me. and what happens at renewal? is it okay when it is checked whether the record is still in place or is a new one needed?
With the system i described above the challenge that fulfill the random request is:
The certificate requester must prove that he own the private key for the public key that he anounced in the DNS record.
To prove this the CA send an random 128bit token to the requester that is send back as jwk signed witht the matching private key for the DNS record containing the token from the challenge.
It’s rather hard to find: It’s part of the in-progress guidelines being discussed by the Domain Validation Working Group of the CA/B Forum. I’d recommend looking up the CA/B Forum Public mailing list and looking through the archives for “domain validation” and “ballot”.
but the CABF seriously needs help. who in their right mind would lock out private people of HTTPS .onion (I think most of the prople using TOR are oribably normal people) certs?
ya know tthose things have EV as requirements and individuals cannot get EV certs, so well…
and it’s similar tohis random thing. the question is how is this thing handled exactly? is it re-useable like in “make it once and get your certs as long as it stays active” or would you actually have to make a new one everytime?
@jsha I have to say that it is very thin for an CA to say that their policy requirements are based on one mail in an mail list.
And not based on the official documents that stand behind the mailing list. I checked
And no place mention the random 128bit token. Instead all places mention that it is legal to validate based on public announced contact. Like mail in whois and i think an public announced public key would be equivalent.
In my eyes there are an order of trust.
a) Without DNS-SEC
Data from Whois Record
DNS-Entry
Port < 1024 of A or AAAA Record
b) With DNS-SEC
Whois Record (If DNS-SEC secured) , DNS-Entry
Port < 1024 of A or AAAA Record
So requesting approval via mail based on whois is ok according to CAB.
Data published on FQDN on demand of CA is ok.
So signed request based on DNS should be ok to.
Maybe someone could ask this in the cab forum.
TBH I’m a bit surprised this wasn’t implemented for dns-01, just seems to much easier and useful for everyone without the limitations of the current implementation (separate dns entries for each domain, dns provider with api for automation, auth for dns api on every server to be able to use real automation (this especially is a showstopper))
Per @kelunik’s note from a couple of years ago (!), this would be better directed to the ACME working group at IETF. This forum isn’t actively used for protocol standardization discussions.