Hi,
When I obtain a certificate with a dns challenge, it is valid for 90 days.
For the renewal, do I need to set a new TXT record each time or can I reuse the same ?
Thanks
Hi @iAmoric
you need a new txt record. Every order has a challenge, a challenge has a token, there is a hash value computed, this is the dns-txt-entry.
New order -> new Challenge -> new token -> new dns-entry.
Thanks for the clarification!
@JuergenAuer is there something official about that ? I mean, maybe in the RFC ? I can’t find it
The DNS challenge and how the key-authz is hashed is described in https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-8.4 .
The fact that authorizations expire is mentioned in https://tools.ietf.org/html/draft-ietf-acme-acme-12#section-7.1.4 , but I believe that the part where “you need to get a new authorization at renewal” is a question left up to the CA policy. For Let’s Encrypt, which participates in the WebPKI, this policy is driven by the CA/Browser Forum Baseline Requirements. In Let’s Encrypt’s case, last I heard, valid authorizations expire after 30 days, but other CAs certainly work differently.
Edit: The Let’s Encrypt CPS also provides some more specific information about how they authorize issuance: https://letsencrypt.org/documents/isrg-cps-v2.3/#3-2-2-authentication-of-organization-and-domain-identity , which largely repeats what’s in the current ACME draft.
Ok, so with Let’s Encrypt, if I renew the certificate before the 30 days, I can reuse the same authorization ?
And if I do that, will the authorization be updated and valid for 30 new days ?
Haha. No, the expiration of any authorization is immutable 
. After all, it is intuitive - you have not proven control over the domain again, you’re just relying on a previous proof.
But I suppose you could technically get a good 119-120 days of certificate coverage out of a single authorization.
Yes ok that’s what I thought. It’s binding to set the txt record each times…
But thanks for the explanations !
The dns-entry (also the file-name and the file-content of the http-01 - challenge) is computed using the token of the Challenge-Object and a hash-value of the account key.
This token of the Challenge-Object must have a Token Entropy:
11.3. Token Entropy
The http-01, and dns-01 validation methods mandate the usage of a
random token value to uniquely identify the challenge. The value of
the token is required to contain at least 128 bits of entropy for the
following security properties.
The token is something like FVA4t8uL3LFzp7BHGYdry_QJ3AJ29dzvmz7auqajoyc. So two different challenges should never have the same token.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.