[PR #728] [CLOSED] Don't assume order status to be valid, retry if needed #910

New Issue

2025-12-29T01:29:57+01:00

adam commented

2025-12-29 01:29:57 +01:00

📋 Pull Request Information

Original PR: https://github.com/dehydrated-io/dehydrated/pull/728
Author: @Rogdham
Created: 4/1/2020
Status: ❌ Closed

Base: master ← Head: order_status_retry

📝 Commits (1)

d4aeec2 Don't assume order status to be valid

📊 Changes

1 file changed (+23 additions, -3 deletions)

View changed files

📝 dehydrated (+23 -3)

📄 Description

Fixes #673. Replaces & closes #639.

The issue is well described by @alexzorin in #673: the status of the orders can be different from valid, in which case we should retry fetching the certificate.

Per https://tools.ietf.org/html/rfc8555#section-7.1.3

status (required, string): The status of this order. Possible values are "pending", "ready", "processing", "valid", and "invalid". See Section 7.1.6.

To get the certificate, we need to call the order URL. It is not 100% clear in the RFC where to find that URL, but the consensus seems to be the Location header when posting a new order:

RFC shows that in the "typical sequence of requests"
This thread on Let's Encrypt forum
Other ACME clients doing that as well (e.g. certbot, acme-tiny)

So this is what I am doing here.

Unfortunately, it seems to be difficult to get both the response and the response header of the new order request, due to bash / the way the code is organised (we would need to store in two separate variables stdout and fd 4, and that seems rather difficult).

So I am doing two requests instead of one when creating the order:

Create the order and get the order URL from the Location header;
Retrieve the order to get various data from the body.

Feel free to offer better alternatives!

Between retries, I am waiting 2 seconds. For comparison:

certbot is waiting 1 second;
acme-tiny is waiting 2 seconds.

Finally, I did not change the way things are handled in ACMEv1, I'm not sure if it is worth looking into.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/dehydrated-io/dehydrated/pull/728 **Author:** [@Rogdham](https://github.com/Rogdham) **Created:** 4/1/2020 **Status:** ❌ Closed **Base:** `master` ← **Head:** `order_status_retry` --- ### 📝 Commits (1) - [`d4aeec2`](https://github.com/dehydrated-io/dehydrated/commit/d4aeec2d7dceef521a7a699f62d5d89ba8a3b91c) Don't assume order status to be valid ### 📊 Changes **1 file changed** (+23 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `dehydrated` (+23 -3) </details> ### 📄 Description Fixes #673. Replaces & closes #639. --- The issue is well described by @alexzorin in #673: the status of the orders can be different from `valid`, in which case we should retry fetching the certificate. Per https://tools.ietf.org/html/rfc8555#section-7.1.3 > status (required, string): The status of this order. Possible values are "pending", "ready", "processing", "valid", and "invalid". See Section 7.1.6. --- To get the certificate, we need to call the order URL. It is not 100% clear in the RFC where to find that URL, but the consensus seems to be the `Location` header when posting a new order: - [RFC shows that in the "typical sequence of requests"](https://tools.ietf.org/html/rfc8555#section-7.1) - [This thread on Let's Encrypt forum](https://community.letsencrypt.org/t/is-the-location-header-of-an-new-order-the-orders-url-in-boulder-letsencrypt/112632) - Other ACME clients doing that as well (e.g. [certbot](https://github.com/certbot/certbot/blob/809cb516c918575bc1688141dfe9b4da001d6570/acme/acme/client.py#L674), [acme-tiny](https://github.com/diafygi/acme-tiny/blob/0a9afb2b72bafad29d172f9d3d704ef979530fe3/acme_tiny.py#L159)) So this is what I am doing here. Unfortunately, it seems to be difficult to get both the response and the response header of the new order request, due to bash / the way the code is organised (we would need to store in two separate variables `stdout` and `fd 4`, and [that seems rather difficult](https://stackoverflow.com/q/11027679)). So I am doing two requests instead of one when creating the order: 1. Create the order and get the order URL from the `Location` header; 2. Retrieve the order to get various data from the body. Feel free to offer better alternatives! --- Between retries, I am waiting 2 seconds. For comparison: - [certbot](https://github.com/certbot/certbot/blob/809cb516c918575bc1688141dfe9b4da001d6570/acme/acme/client.py#L751) is waiting 1 second; - [acme-tiny](https://github.com/diafygi/acme-tiny/blob/0a9afb2b72bafad29d172f9d3d704ef979530fe3/acme_tiny.py#L69) is waiting 2 seconds. --- Finally, I did not change the way things are handled in ACMEv1, I'm not sure if it is worth looking into. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

adam added the pull-request label 2025-12-29 01:29:57 +01:00

adam closed this issue

2025-12-29 01:29:57 +01:00

adam referenced this issue

2025-12-29 02:18:48 +01:00

[PR #943] dehydrated#910 hexdump not always available #970

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/dehydrated#910