Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. https://crt.sh/?q=example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
It produced this output: Status is pending, but when we immediately request this again, it says Valid
My web server is (include version): N/A
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you’re using Certbot):
Questions:
Some domains were valid by ACMEv1, and when we switch over to ACMEv2, ACMEv2 authz link immediately returns valid, which seems to honor the domain validation from ACMEv1. But we also find some domains ACMEv2 requires for re-invalidate. The question is: does it base on some internal criteria such as how close to expiry? if it does, how close to expiry would trigger a re-validation?
The decision is based on when the authorization was last successfully validated. I believe the current cache time is around 30 days. So longer than that, and you’ll have to re-validate. Shorter and you don’t.
Thanks. How shorter? we observed one case in QA that 12 days closer to expiration date, they got re-validate requests…i.e. ACME v2 doesn’t return valid.
But we also observed one case in Prod that one day old domain validation, ACME v2 returns valid.
We just tested a case in Production, one domain www.dv-l1-1-22-2020.webexp-ipqa1.com was validated via ACMEv1, and expiry: 2020-02-21 23:33:12+00
And when we switched it to ACMEv2, it requires a new set of tokens and expiry changed, basically requires re-validate.
Details:
(1) Valid record from ACMEv1
| id | domain | location | status | request_timestamp | final_timestamp | expires | combinations | errors | job_id | le_account_id | error_type | error_detail | validation_status | version | le_order_id |
Is this a sufficient amount of information to answer the question? The cutover from from v1 to v2 will be much easier if domains validated in v1 remain valid until their expiry when checked from v2 API, but it does not appear to be the case.
I have not checked this with the CA staff, but I believe that these two endpoints are using different backend databases for this purpose, and the safest assumption is that authorizations won’t carry over from one endpoint to the other.
It's the same storage backend between API versions but we explicitly do not carry over ACME v1 authorizations to ACME v2. This was a decision we made prior to launcing the V2 API. See the "Existing Accounts" clause of the v2 API announcement:
Existing ACME accounts from the production V1 API will work with the production V2 API. Authorizations held by a V1 account will not be usable in the V2 environment - you must revalidate your domains for use with ACME v2. Similar to ACMEv1, accounts from the V1 or V2 staging environment will not work in the production environment.
