TXT In order to understand how it works


Hello and thanks for your great job,
My question is about how TXT challenge is working.
Please be indulgent :slight_smile:
Why we need to change the TXT token challenge each renew ? even if the ip address are not changing.
(Just to understand the security risk please)
Best regards.

Proposal: Easier way to renew certificates

Hi @panpansh,

This is our interpretation of an industry rule that is created to ensure that the person requesting each certificate still controls the associated domain name. These rules are created by the CA/Browser Forum

It’s possible that this rule or our interpretation is stricter than necessary in some circumstances, but we have to err on the side of caution—issuing a certificate inappropriately is a big problem.


Thank you for your answer it’s very kind of you.
In case today I have the domain name “helloworld.com” using the ip address to get a certificate. Today I am getting a certificate valid until April 3, 2019.
When renew is needed, If the token is still present, and the source ip address remains the same, does this necessarily mean that the owner remains the same ?
Can this be yes only if dnssec is used ?
(I specify, I don’t know, it’s a constructive question).


I believe that this could be valid, but I guess it still falls outside of our interpretation of the industry rules. (@jsha, would you like to address this?)


Nope, the token is explicitly required to change each time under the BRs.


Per section 4.2.1, CAs can reuse validations for up to 825 days.

On or after March 1, 2018, the CA obtained the data or document from a source specified under
Section 3.2 or completed the validation itself no more than 825 days prior to issuing the Certificate. In no case may a prior validation be reused if any data or document used in the prior validation was obtained more than the maximum time permitted for reuse of the data or document prior to issuing the Certificate.

(Let’s Encrypt currently has authorizations expire after 30 days.)

For validation, section 1.6.1 explains what Random Values, Request Tokens, Required Website Content and Test Certificates are, and sections,, and (or outline the validation methods Let’s Encrypt uses.

They largely require that validation information is not reused, e.g.:

If a Random Value is used, the CA SHALL provide a Random Value unique to the Certificate request and SHALL not use the Random Value after (i) 30 days or (ii) if the Applicant submitted the Certificate request, the timeframe permitted for reuse of validated information relevant to the Certificate …

ISTM a Request Token that includes a timestamp, or a Test Certificate, can be reused for up to 30 days. That’s not especially useful, though.

Let’s Encrypt hypothetically could allow authorizations to be reused for longer, maybe even for different amounts of time based on circumstances. But that’s not going to happen.

I don’t know if there was a concrete reason for the BR requirements about one-time-use validation information. It’s hygienic, but not necessary, as far as I can tell. The CABF are not likely to go to a large amount of effort to remove a rule that isn’t very controversial and provides a small security benefit, though.


it is not often easy to judge the actual security profit score.
On the other hand, should “let’s encrypt” necessarily issue a certificate only if DNSSEC is used?
Because today a certificate is issued without verification of this.


We are many many years away from placing such a requirement on ALL certs (it may never come to pass).

But I wonder… Should there be a separate DVDS type cert?
[Domain Validated (by) DNSSEC]
…or a DS tag?
Asumming “YES” - it can and should be done: What would that DS validation look like?
How would it “work”?
There are currently too many moving parts that are expected to be allowed to move to fit this scenario - where: since none of the parts have moved/changed it must all still be the same; and thus if authentication has been previously allowed it should continue to be allowed (without any further check nor challenge).