I was issued a certificate of my domain by using a Let’s encrypt account, so that I can control the domain.
In addition to this, by using another new account, I could also be issued another certificate of the same domain. But I found that domain validation was required to the old account.
Is this behavior derived from the service specification of Let’s encrypt?
Or, is there any reference such as IETF draft describing about this?
(As long as I looked up, I couldn’t find any helpful references.)
Can you expand on what you mean here?
If the question is about cached authorizations I think @mnordhoff has already answered in the other thread you started: Any reference about not needing validation after renewing a cretificate? - #2 by mnordhoff
Thank you for replying!
But I found that domain validation was required to the old account
The old account means the first account to issue a certificate.
In the question, Any reference about not needing validation after renewing a cretificate?, the certificate is renewed (replaced). There is only one account.
But, here in this question, It differs in that there are multiple accounts.
Let me describe the detail chronologically:
In the step 3, It was needed to perform domain validation for the domain even though it was already done in the step 1.
Therefore, I think domain validation for the same domain which was performed previously is abolished. Is this true?
And if yes, as I explained earlier,
Is this behavior derived from the service specification of Let’s encrypt?
Or, is there any reference such as IETF draft describing about this?
(As long as I looked up, I couldn’t find any helpful references.)
For what it's worth, I just tried this exact sequential scenario, and C did not require reauthorization, the authz from A was assigned into the order.
Furthermore, I added a step "D" (Account B), and even though Certbot prompted me to create a new TXT record, it was not actually enforced (I removed the TXT record underlying the authz from certificate B), and a new certificate was issued anyway.
Is it the case perhaps that Certbot's wording is the reason for your confusion?
For what it’s worth, I just tried this exact sequential scenario, and C did not require reauthorization, the authz from A was assigned into the order.
Perhap you are connecting to the staging environment.
Certainly, when I tried in the environment (https://acme-staging.api.letsencrypt.org/directory), the domain validation was not necessary.
However, when I tried it in the production environment (https://acme-v01.api.letsencrypt.org/directory), it seems that domain verification is also performed as I described in step 3 (also as far as I see the access log of http daemon).
I think this question is meaningful because of perspective of security.
I worry about whether someone can continue to manage certificates with the account if I transfers the domain to him within the cache period.
They were real certificates from the (current) production ACME v2 environment. The v1 environment has never been conformant with the IETF drafts anyway - you should use the v2 environment only for any current integration.
The authorization/order flow for v1 is quite different, and I haven't tested what happens there. I don't think anybody should be relying on authzs being cached or not, that seems to be purely a question of CA + CABF policy and not covered by ACME.
Not sure exactly what you mean, but it's definitely the case that there is a hypothetical danger period (authz cache period) where you've lost control of the domain but are still able to mint new certificates.
Though doing so violates section 3.1 of the Subscriber Agreement.
Can you share the domain name(s) or serial numbers for these certificates? I agree with @_az - this shouldn't have the affect you're describing and I think there is likely another explanation.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.