Let’s Encrypt API doesn’t return a 404 when attempting to poll a completed challenge (e.g. https://acme-v01.api.letsencrypt.org/acme/authz/<challenge> )
I don’t have a great understanding of the inner workings of Boulder, but I see from the changelog that a lot of it centered restricting certain functions to DNS identifier types.
jsha is away until some time next week apparently, but it looks like Let’s Encrypt recently re-enabled the authz2 feature flag in production. That change wouldn’t be visible in git but you can infer it from looking at new orders.
There was another thread related to authz2 recently, maybe you can find some useful info in there.
The structure of authorization and challenge URLs is not guaranteed and shouldn’t be assumed by clients. As far as I am aware the x/crypto/acme package correctly derives authorization and challenge URLs from Location headers (and in order objects for the V2 API). If your client is directly constructing authorization or challenge URLs using their IDs it is likely to be quite brittle to any Boulder changes.
Thank you everyone who responded. FWIW, our client implementation was attempting to convert challenge URLs to authz URLs, and it got tripped up on the change in the base path in authv2. Thanks for pointing me in the right direction!
Just in case you haven't figured out a work-around already, there's an RFC-8555 supported way of doing this (that works in ACME v1 as well) that doesn't require manipulating URLs: Challenge objects are returned with a Link header with an "up" relation with the authorization's URL.
Here's an ACME v2 response to a GET for a challenge URL. The relevant headers would be the same for ACME v1: