These unusual authz-v3 authorization URLs worked and domain got validated by our certificate client at the time of issuance of the certificate (16/08/2019)
One common thing found for these domains is they all have the validity upto 22-09-2019 00:00 (unusually more than 30 days of validity)
Now those authorizations URLs are not working & throwing errors as follows,
{
"type": "urn:ietf:params:acme:error:malformed",
"detail": "No such authorization",
"status": 404
}
Now we couldn't reissue certificates containing such authz-v3 authorization URL validated domains. Getting the below error at the time of finalizing order,
Error Status : 403
Error type : urn:ietf:params:acme:error:orderNotReady
Error detail : Order's status ("pending") is not acceptable for finalization
Kindly help us in solving this issue.
Also kindly explain to us what are those unusual authz-v3 URLs
Note: Our Certificate client is designed to not validate a domain if its status is already valid.
authz-v3 is just an implementation detail of the server software that Let's Encrypt uses, so it can distinguish between a previous and current scheme of storing authorizations in the database.
It's not something that ACME clients need to worry about. ACME clients just use whatever authorization URLs the server includes in an order.
If you have an order where all of the authorizations are status: "valid" but cannot be finalized, could you provide the URL to that order?
If an authorization exists in the database but is expired, you will receive the "Expired authorization" error.
If the expired authorization was subsequently purged in database maintenance (as in, completely deleted), then you will receive the "No such authorization" error.
There is a third thing that could have happened, and that is that Let's Encrypt had the new authz URLs enabled, and subsequently disabled them. This might result in them producing the "No such authorization" error as well.
I don't know how that could happen, but I don't have a way to verify whether it's true or not so ¯\(ツ)/¯.
It sounds like your client may be making assumptions about authorizations that are likely to cause breakage (and possibly already has). While the Let’s Encrypt API does, internally, allow the reuse of already validated authorizations when creating a new order this behaviour is not guaranteed. Your client should not assume that if it has previously validated an authorization for a domain name that when creating a new order the same authorization will be re-used as this is an internal implementation detail which may change at any time without prior warning.
A robust client should always check the authorizations returned with a new order and try to complete any that are returned in a pending state.
Your client should not assume that if it has previously validated an authorization for a domain name that when creating a new order the same authorization will be re-used as this is an internal implementation detail which may change at any time without prior warning.
Let me give an example case,
I have a certificate with 99 domains as Subject Alternative Names where all the 99 domains are valid up to the next 29 days. Now I'm adding a domain along with the existing 99 domains to the same certificate and reissuing it. Now our client will request validation only for this newly added domain alone and request for a new certificate after successful validation. This is how the client worked successfully for more than 4 years.
This reduces the certificate issuance time and to & fro API calls between the client and the server in multifold.
A robust client should always check the authorizations returned with a new order and try to complete any that are returned in a pending state.
Also, it would be helpful if you could explain the concept behind the validity of 30 days for a domain if the client should have to validate every time the already validated domain for every new order.
I think @roland is trying to say that just because it has worked doesn't mean it will continue to work because the ACME spec doesn't guarantee it. It also doesn't mean it will work with other ACME providers. The best defensive coding stance for a client is to always check the status of all authorizations in a new order.
99 extra requests in your example is only seconds of additional delay. If all of the previous authorizations are still valid, there's no additional server round trips beyond that first check. And the ACME server is already expecting the traffic because that's how the spec is supposed to work.
