opened 08:49PM - 08 Jul 19 UTC
closed 06:55PM - 16 Jul 19 UTC
layer/api
area/wfe
kind/bug
We use the presence of the `authz2Prefix` const as part of the determination pro…cess for whether a given authz URL is for a v2 authorization or a v1 authorization (Note: Not ACME versions, but internal authorization schema versions):
https://github.com/letsencrypt/boulder/blob/e3f797f9dcafbc0432185bfa54a5f2c17d531e10/wfe/wfe.go#L63
Note that this constant is expressed **without** the trailing `/`.
Later in ACME v1 `wfe.Authorization` when the `NewAuthorizationSchema` feature flag is enabled we check for the `authz2Prefix` at the beginning of a prospective authz ID URL to determine if it is a v2 authorization or not. The intent is to match the "v2/" path component but since the const is expressed without the `/` it is only checking for the "v2" prefix. If the prefix is present, we use the new RPC to try and find the ID after stripping the prefix and a trailing `/`:
https://github.com/letsencrypt/boulder/blob/e3f797f9dcafbc0432185bfa54a5f2c17d531e10/wfe/wfe.go#L1396-L1410
If the authorization ID naturally begins with "v2" (e.g. `v2mvy-6xXeJANcWyrHYtqwhb5QsqxZ6ZU_iGU3y8KD8"`) as a result of randomness it will inappropriately be considered a v2 authorization because of the const being present as a prefix. We will try to strip "v2/" from the ID (which will not do anything in this case) and then look it up as if it were a V2 authorization. In this case it's a v1 authorization that happens to begin with a "v2" so we don't find the authz in the v2 table and return a 404 (e.g. [this forum thread](https://community.letsencrypt.org/t/no-such-authorization/97434/8)).
Note that while the above discusses ACME v1 and links to WFE code this problem is also present in ACME v2 and the WFE2 code:
https://github.com/letsencrypt/boulder/blob/e3f797f9dcafbc0432185bfa54a5f2c17d531e10/wfe2/wfe.go#L1387-L1388