Domain validation from ACMEv1 to be re-invalidated by ACMEv2

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.

My domain is: www.sps-ionstd-san-sni-newprod-le-17.webexp-ipqa1.com

I ran this command: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2453090296

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?

2 Likes

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.

1 Like

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.

1 Like

Shorter than the authorization object’s expires property…whatever that happens to be.

1 Like

Thanks for confirming, it might be our QA case has some other issue.

1 Like

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 |

| 1822701 | www.dv-l1-1-22-2020.webexp-ipqa1.com | https://acme-v01.api.letsencrypt.org/acme/authz-v3/2419751617 | valid | 2020-01-22 18:00:04.322+00 | 2020-01-22 23:33:18.059+00 | 2020-02-21 23:33:12+00

(2) ACMEv2 requires new token and revalidate:

time: 2020-02-13T19:50:54,319
jobId:
uuid: 1689480d-f6f6-4a7c-ba69-38667e665250
logLine: Fetch challenges. Details at 1689480d-f6f6-4a7c-ba69-38667e665250 in LeTrafficLog
uri: https://acme-v02.api.letsencrypt.org/acme/authz-v3/2801015162
inputData: ‘""’
payload: eyJub25jZSI6IjAwMDJhOTdGQlRPN0x0czBRc3d2Y1BtNmYycndiRnR2Q1YxXzFsM0xFc3pwUXZvIiwiYWxnIjoiUlMyNTYiLCJ1cmwiOiJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9hdXRoei12My8yODAxMDE1MTYyIiwia2lkIjoiaHR0cHM6Ly9hY21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYWNjdC8xMzEifQ…nZygGmj_hVwOqZaFJ_y5IaMDzFQMjgAQd6adUzZieoZzJFok1o2S2FrbCO5TD5c1DNX9eQuFUj1OUAR6bdkFkZd9ahNwIB48_YgUEUA0bKKjGlokfJLtFtrwQE1mhQ41oi7VkwxrD_dncxuP0FJRHc8kjGv4YK_PYT4o_pKMCc6SfQYQLV4NrDUOggOyywHK9xMEF9-KwRdu3R9HAWi9N-rVTs4YlHJIT_EsHELXI9CHmkivH9cCwomH2J2dmo26fuZjiNQlSOod_nexrxDTDJU2fjhA8R3yIdYzeQ56hpJhoQ5XIJYfupXu8VwBYm1mwzpXiE5nTFq3VefBqY6UVw
body: ‘{“payload”:"",“protected”:“eyJub25jZSI6IjAwMDJhOTdGQlRPN0x0czBRc3d2Y1BtNmYycndiRnR2Q1YxXzFsM0xFc3pwUXZvIiwiYWxnIjoiUlMyNTYiLCJ1cmwiOiJodHRwczovL2FjbWUtdjAyLmFwaS5sZXRzZW5jcnlwdC5vcmcvYWNtZS9hdXRoei12My8yODAxMDE1MTYyIiwia2lkIjoiaHR0cHM6Ly9hY21lLXYwMi5hcGkubGV0c2VuY3J5cHQub3JnL2FjbWUvYWNjdC8xMzEifQ”,“signature”:“nZygGmj_hVwOqZaFJ_y5IaMDzFQMjgAQd6adUzZieoZzJFok1o2S2FrbCO5TD5c1DNX9eQuFUj1OUAR6bdkFkZd9ahNwIB48_YgUEUA0bKKjGlokfJLtFtrwQE1mhQ41oi7VkwxrD_dncxuP0FJRHc8kjGv4YK_PYT4o_pKMCc6SfQYQLV4NrDUOggOyywHK9xMEF9-KwRdu3R9HAWi9N-rVTs4YlHJIT_EsHELXI9CHmkivH9cCwomH2J2dmo26fuZjiNQlSOod_nexrxDTDJU2fjhA8R3yIdYzeQ56hpJhoQ5XIJYfupXu8VwBYm1mwzpXiE5nTFq3VefBqY6UVw”}’
responseCode: ‘200’
headers: HttpHeaders({date=[Thu, 13 Feb 2020 19:50:53 GMT], server=[nginx], content-length=[814], x-frame-options=[DENY], link=[https://acme-v02.api.letsencrypt.org/directory;rel=“index”], content-type=[application/json], connection=[keep-alive], boulder-requester=[131], cache-control=[public, max-age=0, no-cache], strict-transport-security=[max-age=604800], replay-nonce=[0001F_5n2P-RHNujnvxbPF8e-TizbUJO6hFhZlVvjvb_rUE]})
response: |-
{
“identifier”: {
“type”: “dns”,
“value”: “www.dv-l1-1-22-2020.webexp-ipqa1.com
},
“status”: “pending”,
“expires”: “2020-02-20T19:50:54Z”,
“challenges”: [
{
“type”: “http-01”,
“status”: “pending”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/chall-v3/2801015162/SH-lvg”,
“token”: “COJ7sQFpXmIdAOZoSDEkeLJcy-nAqp1-c-DuC3-6X98”
},
{
“type”: “dns-01”,
“status”: “pending”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/chall-v3/2801015162/xU5q-w”,
“token”: “COJ7sQFpXmIdAOZoSDEkeLJcy-nAqp1-c-DuC3-6X98”
},
{
“type”: “tls-alpn-01”,
“status”: “pending”,
“url”: “https://acme-v02.api.letsencrypt.org/acme/chall-v3/2801015162/UahiTg”,
“token”: “COJ7sQFpXmIdAOZoSDEkeLJcy-nAqp1-c-DuC3-6X98”
}
]
}
data: None

1 Like

Can someone look into this issue, since we have fresh production data (2/13/2020)? Please let me know if you need more information.

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.

:wave:

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.

Any existing ACME v1 authorizations are ignored by the RA component of Boulder when populating a new order with authorizations.

4 Likes

Thanks for the clarification, @cpu! I guess that answers the question in this thread clearly.

1 Like

A post was split to a new topic: Help with Certbot and ACME v2

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.