Unusual authz-v3 authorization URL

We have our own JAVA Certificate Client for purchasing certificates for our Customer Domains.
Recently we come across few unusual authorization URLs.

Example:

projects.savit.in
https://acme-v02.api.letsencrypt.org/acme/authz-v3/7501213

support.cybercyte.com
https://acme-v02.api.letsencrypt.org/acme/authz-v3/5773806

there are more such domains with such authz-v3 URLs

Usually authorization URL looks like

projects.tradinglgs.com
https://acme-v02.api.letsencrypt.org/acme/authz/5ci8NiHJHZuolGmgNOBlGsjJ32pwf5asgOGHA6fGEAw

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?

1 Like

It’s not something that ACME clients need to worry about. ACME clients just use whatever authorization URLs the server includes in an order

@_az could you kindly explain why those URLs are not working now and throwing an error as malformed
Eg. https://acme-v02.api.letsencrypt.org/acme/authz-v3/5773806

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?

Yes.

https://acme-v02.api.letsencrypt.org/acme/finalize/37025817/906364831
https://acme-v02.api.letsencrypt.org/acme/finalize/37025817/907261025

Expired authorizations get purged from the database.

Neither of those orders are ready to be finalized.

In the first order, only one of two authzs are valid. The other authz is pending.

In the second order, at least one of the authzs is still pending.

1 Like

Expired authorizations get purged from the database.

These Authorizations are not expired and have validity up to 22-09-2019 00:00

Certificate got issued a week before on 16-08-2019 using those authorization URLs. But they aren’t working now.

Check the screenshots,



Also if an Authorization is expired, we must be getting error as follows,

{
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “Expired authorization”,
“status”: 404
}

instead of

{
“type”: “urn:ietf:params:acme:error:malformed”,
“detail”: “No such authorization”,
“status”: 404
}

This is not the authorizations URLs we got at the time of issuance :thinking:

if possible, can you provide one example authz-v3 authorization URL that is valid/invalid/pending

There are two different things that can happen.

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 ¯\(ツ)/¯.

This is what happened.

4 Likes

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.

3 Likes

Thank you @cpu for confirming :slight_smile:

1 Like

Thank you @roland :slight_smile:

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.

5 Likes

Thank you @rmbolger @_az @cpu @roland for your support.
We will make necessary changes in our side. :slight_smile: