Hi all,
I’ve seen a BR/servercert fork and PR created by Michael Slaughter
(https://github.com/slghtr-says/servercert/pull/3/files) that may be
helpful for ACME delegation ultilizing service providers (such as
Cloudflare). This PR introduces support for static DNS TXT record
delegation with a persistent hostname, enabling the delegation of specific
account URIs authorized to issue certificates for a domain name.
This approach leverages DNS TXT records with structured values to
explicitly map domain control to designated account URIs, more secure
granular control to enhancing both security and scalability for domain
validation workflows.
在2025年5月15日星期四 UTC+8 03:05:45<Amir Omidi> 写道：
> > I guess it may be possible to work around these limitations some of the
> time, but it feels strange that hosting providers have to do that, when
> there is no reason why this restriction was created in this validation
> method.
>
> I mean, I wouldn't say *no reason*. Note that this new method does not
> deprecate DNS-01, so the normal DNS-01 challenge works. This method merely
> aims to allow doing DCV delegation to more than one entity.
>
> We needed a stable(ish) value that both the subscriber and the CA have
> access to. Account URI was chosen because it fit that criteria.
>
> The idea for these hosting providers is that they should preferably have
> multiple CA options configured beforehand. But yes, new providers would
> require a manual update.
>
>
> On Wed, May 14, 2025 at 2:58 PM Jesper Kristensen <jespe...@gmail.com>
> wrote:
>
>> I cannot see how a few extra DNS records creates a problem, but I can
>> imagine the timing of when these records need to be changed could cause a
>> problem in some scenarios. For example when a hosting provider needs to
>> change CAs, they would need to ask all customers using this validation
>> method to update their CNAMEs at the same time. Cloudflare, which was given
>> as the example, has changed CAs on short notice in the past when the Let's
>> Encrypt cross-sign expired, so I don't think it is entirely theoretical.
>> Another more hypothetical example could be if the hosting provider needed
>> to change ACME accounts depending on the customer's jurisdiction or other
>> reasons.
>>
>> I guess it may be possible to work around these limitations some of the
>> time, but it feels strange that hosting providers have to do that, when
>> there is no reason why this restriction was created in this validation
>> method.
>>
>> Den ons. 14. maj 2025 kl. 18.45 skrev Ryan Hurst <ryan....@gmail.com>:
>>
>>> Hi Xiaohui,
>>>
>>> Anyone is welcome to propose a new ACME challenge, but I am not sure I
>>> see a problem that needs solving.
>>>
>>> - Multiple DNS records are normal. DNS is designed to store many RRsets
>>> for the same owner name. Delegation operators already publish dozens of A,
>>> AAAA, and TXT records for a single zone. Adding one more CNAME for a second
>>> CA is not an operational burden.
>>>
>>> - Automation already has to write DNS. Modern deployment models rely on
>>> fully automated issuance and renewal. If a CA uses ARI (RFC 9270) or the
>>> account holder needs to re-key, the automation must add or update DNS TXT
>>> records anyway. Whether there is one record or two makes no difference to
>>> that workflow.
>>>
>>> Extra challenge types add complexity. Every new challenge means code,
>>> documentation, compliance review, and interop testing for ACME clients and
>>> CAs. That overhead should buy real security or usability gains. Here the
>>> benefit seems to be avoiding a second record, which does not look
>>> compelling from my perspective.
>>>
>>> If there is a concrete scenario where two CNAMEs cause material pain
>>> like rate limits, cache issues, legacy software it would help to understand
>>> what that issue is. Otherwise the existing dns-01 plus the delegated-label
>>> draft appear to meet the goal without adding a third option to maintain.
>>>
>>> Best,
>>> Ryan
>>>
>>> On Wed, May 14, 2025 at 9:32 AM Xiaohui Lam <inao...@gmail.com> wrote:
>>>
>>>> Hi Amir, and Ryan
>>>>
>>>> I agree with your comments.
>>>> Yes ACME account key needs full lifecycle management(including replace
>>>> mechanism).
>>>>
>>>> Maybe my demand can be satisfied by a new challenge type, rather than
>>>> the digest form generated based on accountkey.
>>>>
>>>> e.g: design a new challenge type`dns-delegation-01`
>>>>
>>>> And Domain name's challenges API:
>>>>
>>>> POST /acme/authz/PAniVnsZcis HTTP/1.1
>>>> Host: example.com
>>>> Content-Type: application/jose+json
>>>>
>>>> {
>>>> "protected": base64url({
>>>> "alg": "ES256",
>>>> "kid": "https://example.com/acme/acct/evOfKhNU60wg";,
>>>> "nonce": "uQpSjlRb4vQVCjVYAyyUWg",
>>>> "url": "https://example.com/acme/authz/PAniVnsZcis";
>>>> }),
>>>> "payload": "",
>>>> "signature": "nuSDISbWG8mMgE7H...QyVUL68yzf3Zawps"
>>>> }
>>>>
>>>> HTTP/1.1 200 OK
>>>> Content-Type: application/json
>>>> Link: <https://example.com/acme/directory>;rel="index"
>>>>
>>>> {
>>>> "status": "pending",
>>>> "expires": "2016-01-02T14:09:30Z",
>>>>
>>>> "identifier": {
>>>> "type": "dns",
>>>> "value": "www.example.org"
>>>> },
>>>>
>>>> "challenges": [
>>>> {
>>>> "type": "http-01",
>>>> "url": "https://example.com/acme/chall/prV_B7yEyA4";,
>>>> "token": "DGyRejmCefe7v4NfDGDKfA"
>>>> },
>>>> {
>>>> "type": "dns-01",
>>>> "url": "https://example.com/acme/chall/Rg5dV14Gh1Q";,
>>>> "token": "DGyRejmCefe7v4NfDGDKfA"
>>>> },
>>>> {
>>>> "type": "dns-delegation-01",
>>>> "url": "https://example.com/acme/chall/D2zX3m9jfIyE4";,
>>>> "token": "DGyRejmCefe7v4NfDGDKfA"
>>>> }
>>>> ]
>>>> }
>>>>
>>>> And requires user to create DNS TXT
>>>> _acme-challenge_cloudflare.www.example.org 300
>>>> TXT keyAuthorization=token || '.' || base64url(Thumbprint(accountKey))
>>>>
>>>> And perform challenge(delegation can only be alphanumeric, no special
>>>> characters allowed):
>>>>
>>>>
>>>> POST /acme/chall/D2zX3m9jfIyE4 HTTP/1.1 Host: example.com
>>>> Content-Type: application/jose+json { "protected": base64url({ "alg":
>>>> "ES256", "kid": "https://example.com/acme/acct/evOfKhNU60wg";, "nonce":
>>>> "Q_s3MWoqT05TrdkM2MTDcw", "url": "
>>>> https://example.com/acme/chall/D2zX3m9jfIyE4"; }), "payload":
>>>> base64url({
>>>>
>>>>
>>>> "delegation": "cloudflare"
>>>>
>>>>
>>>>
>>>> }), "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" }
>>>>
>>>> How about new challenge type like this? But we need a draft a new RFC
>>>> if it makes sense.
>>>>
>>>> Thanks
>>>> 在2025年5月15日星期四 UTC+8 00:13:35<Ryan Hurst> 写道：
>>>>
>>>>> Remember that an ACME account key is just another cryptographic key
>>>>> that requires full lifecycle management. This involves keeping it secure,
>>>>> rotating it regularly to limit the window an attacker has if it is ever
>>>>> compromised, and eventually replacing it with a key using stronger or
>>>>> newer
>>>>> algorithms (for example, moving to ML-DSA for post-quantum security). In
>>>>> practice, ACME account keys are no more secure than the keys used for TLS
>>>>> certificates, since most implementations store them on disk protected
>>>>> only
>>>>> by basic filesystem ACLs.
>>>>>
>>>>> On the positive side, because account keys see fewer operations, they
>>>>> can be generated and stored in hardware such as a TPM, which offers
>>>>> stronger protection without impacting TLS performance or algorithm
>>>>> choices.
>>>>> This is why it makes sense to decouple the domain-control label from the
>>>>> account key itself, but the specification must still acknowledge that
>>>>> these
>>>>> keys require proper management. Failing to do so would lead to fragile
>>>>> implementations and discourage sound key-management practices.
>>>>>
>>>>> Ryan
>>>>>
>>>>> On Wed, May 14, 2025 at 9:10 AM Xiaohui Lam <inao...@gmail.com> wrote:
>>>>>
>>>>>> Hi Amir,
>>>>>>
>>>>>> Thank you for post expanding contents.
>>>>>>
>>>>>> > I don't doubt this, but most of what we do in this space is
>>>>>> planning for worst case scenarios. As ACME is meant to facilitate
>>>>>> short-lived credentials, I don't think it would be responsible to build
>>>>>> features that rely on long (forever?) lived keys.
>>>>>>
>>>>>> How do we solve this problem?
>>>>>> - Let's encrypt returns account URI:
>>>>>> https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu (Just an
>>>>>> example and does not represent the actual content.)
>>>>>> - base32(SHA-256(
>>>>>> https://acct.acme-v02.letsencrypt.org/acct/tjvsrsls89gu9ssu)[0:9])
>>>>>> - GTS returns a different account URI:
>>>>>> https://acme-02.pki.google/account/ilctdkn9ifnueocs (Just an example
>>>>>> and does not represent the actual content.)
>>>>>> - base32(SHA-256(
>>>>>> https://acme-02.pki.google/account/ilctdkn9ifnueocs)[0:9])
>>>>>>
>>>>>> This situation (scenario of Cloudflare's multiple backup certificate)
>>>>>> CA requires two different dnshostname, and Cloudflare customers need to
>>>>>> create DNS record twice.
>>>>>>
>>>>>> Is there other way to reduce configuration overhead for users?
>>>>>>
>>>>>> Thank you.
>>>>>> 在2025年5月15日星期四 UTC+8 00:01:57<Amir Omidi> 写道：
>>>>>>
>>>>>>> > Based on my experience, instances of ACME account key compromise
>>>>>>> are extremely rare. I also have full confidence in Cloudflare’s robust
>>>>>>> security operations capability - such account key compromises are
>>>>>>> highly
>>>>>>> unlikely to occur internally at Cloudflare.
>>>>>>>
>>>>>>> I don't doubt this, but most of what we do in this space is planning
>>>>>>> for worst case scenarios. As ACME is meant to facilitate short-lived
>>>>>>> credentials, I don't think it would be responsible to build features
>>>>>>> that
>>>>>>> rely on long (forever?) lived keys.
>>>>>>>
>>>>>>> Furthermore, the issue isn't only key compromise. There are many
>>>>>>> circumstances why this key might change. For example:
>>>>>>>
>>>>>>> 1. Regulatory requirements on not having long-lived keys.
>>>>>>> 2. There being a runtime problem during generation of this ACME
>>>>>>> account key that is discovered in the future.
>>>>>>> 3. Moving away from ECC/RSA keys in the future.
>>>>>>>
>>>>>>> I feel very strongly that we should not be building a feature that
>>>>>>> takes a strong dependency on the life of a key, where it doesn't really
>>>>>>> need to.
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> On Wed, May 14, 2025 at 11:57 AM Xiaohui Lam <inao...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Amir,
>>>>>>>>
>>>>>>>> Thank you for your response, specially posted here, your concern
>>>>>>>> when drafting the RFC.
>>>>>>>>
>>>>>>>> Based on my experience, instances of ACME account key compromise
>>>>>>>> are extremely rare. I also have full confidence in Cloudflare’s robust
>>>>>>>> security operations capability - such account key compromises are
>>>>>>>> highly
>>>>>>>> unlikely to occur internally at Cloudflare.
>>>>>>>>
>>>>>>>> My suggestion is to draft the document to retain both the current
>>>>>>>> account URI-generated suffix and add an account key-generated suffix.
>>>>>>>> This
>>>>>>>> would allow delegate operators (such as Cloudflare) to implement the
>>>>>>>> optimal approach for their customers.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>>
>>>>>>>> 在2025年5月14日星期三 UTC+8 23:17:12<Amir Omidi> 写道：
>>>>>>>>
>>>>>>>>> Hi!
>>>>>>>>>
>>>>>>>>> However, wouldn’t it be more logical to generate this host from
>>>>>>>>> the account public key instead?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> If we think about the entire lifecycle of the ACME account, using
>>>>>>>>> the public key makes less sense. The workflow that I’ve imagined for
>>>>>>>>> this
>>>>>>>>> is as follows:
>>>>>>>>>
>>>>>>>>> 1. Large provider creates ACME accounts on ACME enabled CAs.
>>>>>>>>> 2. Large provider ensures that the CA’s have rate limits in place
>>>>>>>>> to allow them to do large number of issuances.
>>>>>>>>> 3. Large provider communicates these stable strings to the
>>>>>>>>> customer to set as CNAME records for DCV delegation.
>>>>>>>>>
>>>>>>>>> Now, if we use the public key, these are no longer stable URLs. We
>>>>>>>>> effectively have a long lived key, where replacing that key ends up
>>>>>>>>> requiring every single customer to change their CNAME records.
>>>>>>>>>
>>>>>>>>> With the design that is currently in place, we can use
>>>>>>>>> https://datatracker.ietf.org/doc/html/rfc8555#section-7.3.5 to
>>>>>>>>> rollover the account keys, without causing disruptions to the end
>>>>>>>>> users.
>>>>>>>>>
>>>>>>>>> Hope this answers the inquiry!
>>>>>>>>>
>>>>>>>>> On May 14, 2025, at 10:42 AM, Xiaohui Lam <inao...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> It should be following:
>>>>>>>>>
>>>>>>>>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "
>>>>>>>>> example.org.googletrustservice.acme-delegate.cloudflare.com", for
>>>>>>>>> Google Trust Service
>>>>>>>>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "
>>>>>>>>> example.org.letsencrypt.acme-delegate.cloudflare.com", for Let's
>>>>>>>>> Encrypt
>>>>>>>>>
>>>>>>>>> Sorry for my typo
>>>>>>>>> 在2025年5月14日星期三 UTC+8 22:39:59<Xiaohui Lam> 写道：
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> I came across Cloudflare’s blog (
>>>>>>>>>> https://blog.cloudflare.com/zh-cn/introducing-dcv-delegation),
>>>>>>>>>> which mentions an RFC draft Automated Certificate Management
>>>>>>>>>> Environment
>>>>>>>>>> (ACME) DNS Labeled With ACME Account ID Challenge. This draft
>>>>>>>>>> proposes a
>>>>>>>>>> new domain control verification (DCV) method using following DNS
>>>>>>>>>> record:
>>>>>>>>>> _acme-challenge_ujmmovf2vn55tgye.www.example.org 300 IN TXT
>>>>>>>>>> "LoqXcYV8...jxAjEuX0.9jg46WB3...fm21mqTI"
>>>>>>>>>>
>>>>>>>>>> Key concern of mine revolves around how the validation domain
>>>>>>>>>> name is constructed by prepending the label:
>>>>>>>>>> "_acme-challenge" || base32(SHA-256(Account Resource URL)[0:9])
>>>>>>>>>> The verification DNS host _acme-challenge_[suffix]'s suffix is
>>>>>>>>>> generated from the ACME account URI (account resource URL). However,
>>>>>>>>>> wouldn’t it be more logical to generate this host from the account
>>>>>>>>>> public
>>>>>>>>>> key instead?
>>>>>>>>>>
>>>>>>>>>> Let’s contextualize this with Cloudflare’s use case: they aim to
>>>>>>>>>> allow users to delegate _acme-challenge_[suffix] via CNAME records.
>>>>>>>>>> If we
>>>>>>>>>> use the account URI to generate the DNS host suffix, and Cloudflare
>>>>>>>>>> users
>>>>>>>>>> need to enroll certificates from two CAs - such as
>>>>>>>>>>
>>>>>>>>>> - Let’s Encrypt, and
>>>>>>>>>> - Google Trust Service
>>>>>>>>>>
>>>>>>>>>> Cloudflare will give two CNAME records, e. g:
>>>>>>>>>>
>>>>>>>>>> - _acme-challenge_cd9dtbvvknxwz1mg.example.org 300 IN CNAME "
>>>>>>>>>> example.org.googletrustservice.acme-delegate.cloudflare.com",
>>>>>>>>>> for Let's Encrypt
>>>>>>>>>> - _acme-challenge_on0ikkqoklpbadex.example.org 300 IN CNAME "
>>>>>>>>>> example.org.letsencrypt.acme-delegate.cloudflare.com", for
>>>>>>>>>> Google Trust Service
>>>>>>>>>>
>>>>>>>>>> They would have to create two separate CNAME records (due to
>>>>>>>>>> different DNS hosts and values for every CA).
>>>>>>>>>>
>>>>>>>>>> In contrast, if the DNS host suffix is generated from the account
>>>>>>>>>> public key, Cloudflare users would only need to create one CNAME
>>>>>>>>>> record for
>>>>>>>>>> delegation. This streamlines the process, enhanced
>>>>>>>>>> security(publickey is
>>>>>>>>>> far secure than an url string) and reduces configuration overhead
>>>>>>>>>> for users.
>>>>>>>>>>
>>>>>>>>>> Thoughts?
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> You received this message because you are subscribed to the Google
>>>>>>>>> Groups "dev-secur...@mozilla.org" group.
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to dev-security-po...@mozilla.org.
>>>>>>>>> To view this discussion visit
>>>>>>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org
>>>>>>>>>
>>>>>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/c8a84911-53fa-418f-b742-9109157c1997n%40mozilla.org?utm_medium=email&utm_source=footer>
>>>>>>>>> .
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>>>>>> Groups "dev-secur...@mozilla.org" group.
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to dev-security-po...@mozilla.org.
>>>>>>
>>>>> To view this discussion visit
>>>>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org
>>>>>>
>>>>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/7ea62291-2e4c-4500-a4b2-d0d7ed7a43d7n%40mozilla.org?utm_medium=email&utm_source=footer>
>>>>>> .
>>>>>>
>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "dev-secur...@mozilla.org" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to dev-security-po...@mozilla.org.
>>> To view this discussion visit
>>> https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZddyDwGB0WMCFLzEJg531gqV%3D7Vn1EG0WRn60Ncy%2BHRg%40mail.gmail.com
>>>
>>> <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CALVZKwZddyDwGB0WMCFLzEJg531gqV%3D7Vn1EG0WRn60Ncy%2BHRg%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"dev-security-policy@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dev-security-policy+unsubscr...@mozilla.org.
To view this discussion visit
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/9e4b926a-76a5-4453-9d13-a812c62740fen%40mozilla.org.
