[GH-ISSUE #1094] [Bug] Let's Encrypt Staging ARI didn't used

kerem commented

2026-03-03 01:05:38 +03:00

Owner

Originally created by @xlionjuan on GitHub (Dec 8, 2025).
Original GitHub issue: https://github.com/certimate-go/certimate/issues/1094

Release Version / 软件版本

v0.4.8

Description / 缺陷描述

根據 https://github.com/certimate-go/certimate/pull/426
Certimate 已經實現了 ARI 支持，但我在使用 Let's Encrypt Staging 測試時，發現 log 中沒看到在嘗試獲取 ARI 資訊的訊息，並且又會再去申請一次證書

Steps to reproduce / 复现步骤

「阻止 ARI 续期」是關的
重複申請我設定為 7 天，使用 shortlived profile 進行測試
使用 DNS-01 Challenge

其他見 Yaml

nodes:
  - id: "3_DeHjVpQN7TGQAnRf3WE"
    type: "start"
    name: "开始"
    config:
      trigger: "manual"
  - id: "sNYV-h6y4qp8MMrttwF6l"
    type: "tryCatch"
    name: "尝试执行…"
    blocks:
      - id: "5j808WwHa6aeqZ3SJ0pFO"
        type: "tryBlock"
        name: ""
        blocks:
          - id: "4qUmrJZB33aTjRZ-ox6e3"
            type: "bizApply"
            name: "申请"
            config:
              acmeProfile: "shortlived"
              caProvider: "letsencryptstaging"
              challengeType: "dns-01"
              contactEmail: "xx@xx.com"
              disableARI: false
              disableFollowCNAME: false
              domains: "*.xxx.com;xxx.com"
              keyAlgorithm: "EC384"
              keySource: "auto"
              nameservers: ""
              provider: "cloudflare"
              providerAccessId: "xxx"
              skipBeforeExpiryDays: 7
          - id: "rfbXZs64gpmGCIEAtgk4j"
            type: "bizDeploy"
            name: "部署"
            config:
              certificateOutputNodeId: "4qUmrJZB33aTjRZ-ox6e3"
              provider: "local"
              providerConfig:
                certPath: "/etc/ssl/certimate/cert.crt"
                format: "PEM"
                keyPath: "/etc/ssl/certimate/cert.key"
                shellEnv: "sh"
              skipOnLastSucceeded: true
      - id: "Z-7nFuL2DxHrWgRmmkdub"
        type: "catchBlock"
        name: "若执行失败…"
        blocks:
          - id: "KpduRtGsDcliOz-ywdNWe"
            type: "end"
            name: "结束"
  - id: "pB3OVe3DY-ULyD4j1K1O3"
    type: "end"
    name: "结束"

對了，Let's Encrypt 不再需要 Email 了，所以請求時可以改用站位符或不送

Logs / 日志

No response

Miscellaneous / 其他

考慮到以後憑證最終會變 47 天，或自願採用 shortlived 6 天憑證，原則上建議續訂邏輯（假設沒 ARI 資訊可用）不應硬編碼（或預設）為剩餘 30 天時執行，應動態地計算憑證效期時長剩 1/3 時續訂

Contribution / 贡献代码

I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

Originally created by @xlionjuan on GitHub (Dec 8, 2025). Original GitHub issue: https://github.com/certimate-go/certimate/issues/1094 ### Release Version / 软件版本 v0.4.8 ### Description / 缺陷描述根據 https://github.com/certimate-go/certimate/pull/426 Certimate 已經實現了 ARI 支持，但我在使用 Let's Encrypt Staging 測試時，發現 log 中沒看到在嘗試獲取 ARI 資訊的訊息，並且又會再去申請一次證書 ### Steps to reproduce / 复现步骤 1. 「阻止 ARI 续期」是關的 2. 重複申請我設定為 7 天，使用 shortlived profile 進行測試 3. 使用 DNS-01 Challenge 其他見 Yaml ```yaml nodes: - id: "3_DeHjVpQN7TGQAnRf3WE" type: "start" name: "开始" config: trigger: "manual" - id: "sNYV-h6y4qp8MMrttwF6l" type: "tryCatch" name: "尝试执行…" blocks: - id: "5j808WwHa6aeqZ3SJ0pFO" type: "tryBlock" name: "" blocks: - id: "4qUmrJZB33aTjRZ-ox6e3" type: "bizApply" name: "申请" config: acmeProfile: "shortlived" caProvider: "letsencryptstaging" challengeType: "dns-01" contactEmail: "xx@xx.com" disableARI: false disableFollowCNAME: false domains: "*.xxx.com;xxx.com" keyAlgorithm: "EC384" keySource: "auto" nameservers: "" provider: "cloudflare" providerAccessId: "xxx" skipBeforeExpiryDays: 7 - id: "rfbXZs64gpmGCIEAtgk4j" type: "bizDeploy" name: "部署" config: certificateOutputNodeId: "4qUmrJZB33aTjRZ-ox6e3" provider: "local" providerConfig: certPath: "/etc/ssl/certimate/cert.crt" format: "PEM" keyPath: "/etc/ssl/certimate/cert.key" shellEnv: "sh" skipOnLastSucceeded: true - id: "Z-7nFuL2DxHrWgRmmkdub" type: "catchBlock" name: "若执行失败…" blocks: - id: "KpduRtGsDcliOz-ywdNWe" type: "end" name: "结束" - id: "pB3OVe3DY-ULyD4j1K1O3" type: "end" name: "结束" ``` 對了，Let's Encrypt 不再需要 Email 了，所以請求時可以改用站位符或不送 ### Logs / 日志 _No response_ ### Miscellaneous / 其他考慮到以後憑證最終會變 47 天，或自願採用 shortlived 6 天憑證，原則上建議續訂邏輯（假設沒 ARI 資訊可用）不應硬編碼（或預設）為剩餘 30 天時執行，應動態地計算憑證效期時長剩 1/3 時續訂 ### Contribution / 贡献代码 - [ ] I am interested in contributing a PR for this! / 我乐意为此提交代码并发起 PR！

kerem

2026-03-03 01:05:38 +03:00

closed this issue
added the
bug

declined
labels

kerem commented

2026-03-03 01:05:39 +03:00

Author

Owner

@fudiwei commented on GitHub (Dec 8, 2025):

目前只在申请证书时使用了 ARI 中的 CertID 字段，用于突破 CA 的速率限制；但并没有使用 SuggestedWindow 作为续期间隔，续期间隔仍以用户自行设置的为准。

@fudiwei commented on GitHub (Dec 8, 2025): 目前只在申请证书时使用了 ARI 中的 `CertID` 字段，用于突破 CA 的速率限制；但并没有使用 `SuggestedWindow` 作为续期间隔，续期间隔仍以用户自行设置的为准。

kerem commented

2026-03-03 01:05:39 +03:00

Author

Owner

@xlionjuan commented on GitHub (Dec 8, 2025):

SuggestWindow 是不可或缺的一部分，除了讓 CA 可以負載平衡，還可以在遇到大量憑證撤銷事件時儘速通知 ACME Client 使其盡快更新憑證

根據 https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients

certificate renewals that utilize ARI will now be exempt from all rate limits. To capitalize on this benefit, renewals must occur within the ARI-suggested renewal window, and the request must clearly indicate which existing certificate is being replaced.

必須遵循 SuggestWindow 才可突破速率限制，並且才是正確的實施
請務必考慮進去

另外根據 ISRG 2025 年報：

https://www.abetterinternet.org/annual-reports

The Internet Engineering Task Force (IETF) has published the latest addition to the ACME protocol, ACME Renewal Information (ARI), as RFC 9773. ARI helps keep the renewal process reliable during unexpected events affecting certificate validity. ARI was initially conceived following incident in January 2022 where we had to revoke approximately two million certificates due to a technical error in our validation processes. ARI allows a Certificate Authority (CA) to advise a software client to perform an early renewal of a certificate in circumstances where the CA knows that an early renewal is helpful or necessary, even if the client would not yet have anticipated the cert needed to be renewed. In the mass revocation scenario, this allows ARI-aware clients to avoid outages due to certificate invalidity, because they can replace their certificates even before the revocation occurs.
互聯網工程任務小組 (IETF) 發布了 ACME 協議的最新擴展——ACME 續期資訊 (ARI)，其 RFC 編號為 9773。 ARI 有助於在證書有效性受到意外事件影響時，確保續期流程的可靠性。 ARI 的構想源自於 2022 年 1 月發生的事件，當時由於驗證流程中的技術錯誤，我們不得不撤銷大約兩百萬個憑證。 ARI 允許憑證授權單位 (CA) 在 CA 認為提前續期證書有益或必要的情況下，建議軟體用戶端提前續期證書，即使用戶端尚未預料到需要續期證書。在大規模憑證撤銷的情況下，支援 ARI 的用戶端可以避免因憑證失效而導致的服務中斷，因為它們甚至可以在憑證被撤銷之前就更換憑證。

還號召所有 ACME Client 開發者將 ARI 加入至 2026 路線圖內

@xlionjuan commented on GitHub (Dec 8, 2025): SuggestWindow 是不可或缺的一部分，除了讓 CA 可以負載平衡，還可以在遇到大量憑證撤銷事件時儘速通知 ACME Client 使其盡快更新憑證根據 https://letsencrypt.org/2024/04/25/guide-to-integrating-ari-into-existing-acme-clients > certificate renewals that utilize ARI will now be exempt from all rate limits. To capitalize on this benefit, renewals must occur within the ARI-suggested renewal window, and the request must clearly indicate which existing certificate is being replaced. 必須遵循 SuggestWindow 才可突破速率限制，並且才是正確的實施請務必考慮進去另外根據 ISRG 2025 年報： https://www.abetterinternet.org/annual-reports > The Internet Engineering Task Force (IETF) has published the latest addition to the ACME protocol, ACME Renewal Information (ARI), as RFC 9773. ARI helps keep the renewal process reliable during unexpected events affecting certificate validity. ARI was initially conceived following incident in January 2022 where we had to revoke approximately two million certificates due to a technical error in our validation processes. ARI allows a Certificate Authority (CA) to advise a software client to perform an early renewal of a certificate in circumstances where the CA knows that an early renewal is helpful or necessary, even if the client would not yet have anticipated the cert needed to be renewed. In the mass revocation scenario, this allows ARI-aware clients to avoid outages due to certificate invalidity, because they can replace their certificates even before the revocation occurs. > 互聯網工程任務小組 (IETF) 發布了 ACME 協議的最新擴展——ACME 續期資訊 (ARI)，其 RFC 編號為 9773。 ARI 有助於在證書有效性受到意外事件影響時，確保續期流程的可靠性。 ARI 的構想源自於 2022 年 1 月發生的事件，當時由於驗證流程中的技術錯誤，我們不得不撤銷大約兩百萬個憑證。 ARI 允許憑證授權單位 (CA) 在 CA 認為提前續期證書有益或必要的情況下，建議軟體用戶端提前續期證書，即使用戶端尚未預料到需要續期證書。在大規模憑證撤銷的情況下，支援 ARI 的用戶端可以避免因憑證失效而導致的服務中斷，因為它們甚至可以在憑證被撤銷之前就更換憑證。還號召所有 ACME Client 開發者將 ARI 加入至 2026 路線圖內 ![Screenshot_20251208-203653.png](https://github.com/user-attachments/assets/4433bbfe-fd1f-4371-a900-86af309ec8a0)

kerem commented

2026-03-03 01:05:39 +03:00

Author

Owner

@xlionjuan commented on GitHub (Dec 8, 2025):

需要留意的是，更新憑證不會讓上一個憑證失效，除非是遭遇不幸的大規模撤銷事件

部署作業是可以安排在其他時間進行的，唯獨續約更新的部分建議遵照 ARI 時間，「不建議」強制在固定時間進行

@xlionjuan commented on GitHub (Dec 8, 2025): 需要留意的是，更新憑證不會讓上一個憑證失效，除非是遭遇不幸的大規模撤銷事件部署作業是可以安排在其他時間進行的，唯獨續約更新的部分建議遵照 ARI 時間，「不建議」強制在固定時間進行

kerem commented

2026-03-03 01:05:39 +03:00

Author

Owner

@ZeroClover commented on GitHub (Dec 8, 2025):

https://community.letsencrypt.org/t/rate-limit-for-short-lived-certificates-exactly-set-of-identifiers/243649/2

根据实际测试，只在 New Order 传入 CertID 不会豁免速率限制

@ZeroClover commented on GitHub (Dec 8, 2025): https://community.letsencrypt.org/t/rate-limit-for-short-lived-certificates-exactly-set-of-identifiers/243649/2 根据实际测试，只在 New Order 传入 CertID 不会豁免速率限制

kerem commented

2026-03-03 01:05:39 +03:00

Author

Owner

@xlionjuan commented on GitHub (Dec 8, 2025):

只想著用 CertID 來試圖繞過速率限制是不妥當的，而是要好好的遵循標準規範實施 ACME 中所列出的規範，大家一起當良好的網路公民

ARI 的誕生除了在遭遇大規模撤銷事件時可以很好的派上用場，另一好理解且重要的就是幫 CA 做負載平衡，人家都給你免費的 CA 了，而且頒發伺服器還承受那麼大的流量。

@xlionjuan commented on GitHub (Dec 8, 2025): 只想著用 `CertID` 來試圖繞過速率限制是不妥當的，而是要好好的遵循標準規範實施 ACME 中所列出的規範，大家一起當良好的網路公民 ARI 的誕生除了在遭遇大規模撤銷事件時可以很好的派上用場，另一好理解且重要的就是幫 CA 做負載平衡，人家都給你免費的 CA 了，而且頒發伺服器還承受那麼大的流量。

kerem commented

2026-03-03 01:05:40 +03:00

Author

Owner

@fudiwei commented on GitHub (Dec 9, 2025):

再次说明，目前的 ARI 实现设计如此，这并不是一个 Bug。

必須遵循 SuggestWindow 才可突破速率限制，並且才是正確的實施

根据实际测试，只在 New Order 传入 CertID 不会豁免速率限制

如果你不在 SuggestedWindow 窗口期内请求签发，自然不会豁免速率限制。

但对于目前 90 天有效期的证书而言，默认配置下的续期间隔一定是在 SuggestedWindow 范围内的（不考虑被 CA 吊销之类的窗口期会缩短这类极端情况）。

用 short-lived 短期证书、并在首次签发后立即再次签发来试图测试 ARI，得不到你想要的结果是理所应当。

一个不精确的比喻：医嘱要求一天两次服药以达到最佳疗效，但某人没有严格遵守每隔 12 小时服一次药的方式，而是选择在每天早、晚餐后服药，而他的作息恰好是 6:00 左右吃早餐、18:00 左右吃晚餐，这也恰好能满足要求。但倘若某天睡懒觉临近中午才起床吃早餐、下午茶吃的太饱而错过晚餐，此时再服药自然会错过最佳疗效，这是理所应当的，而不是反过头来认为“早晚餐后服药”的做法是问题。

如果你希望得到完整的 ARI 支持，你可以开一个新的 Feature Request。但短期内没有计划实施，因为 ARI 要求使用更频繁地客户端检查（即以限制及开销更小的检查流程，来取代限制及开销更大的签发流程），与目前工作流的执行模式并不完全匹配。此外，目前只有 LE 支持 ARI、其余诸如 GTS、ZeroSSL 等 CA 虽然端点中名义上包含 renewalInfo，但其速率限制与此无关（关于速率的部分本身并不是 RFC 规范内的，LE 的做法只是某种副产物），专为特定 CA 提供支持在我看来并不迫切。在有好的实施方案、或更紧迫的时间表之前，我不会贸然行动。

@fudiwei commented on GitHub (Dec 9, 2025): 再次说明，目前的 ARI 实现**设计如此**，这并不是一个 Bug。 --- > 必須遵循 SuggestWindow 才可突破速率限制，並且才是正確的實施 > 根据实际测试，只在 New Order 传入 CertID 不会豁免速率限制如果你不在 `SuggestedWindow` 窗口期内请求签发，自然不会豁免速率限制。但对于目前 90 天有效期的证书而言，默认配置下的续期间隔一定是在 `SuggestedWindow` 范围内的（不考虑被 CA 吊销之类的窗口期会缩短这类极端情况）。用 short-lived 短期证书、并在首次签发后立即再次签发来试图测试 ARI，得不到你想要的结果是理所应当。一个不精确的比喻：医嘱要求一天两次服药以达到最佳疗效，但某人没有严格遵守每隔 12 小时服一次药的方式，而是选择在每天早、晚餐后服药，而他的作息恰好是 6:00 左右吃早餐、18:00 左右吃晚餐，这也恰好能满足要求。但倘若某天睡懒觉临近中午才起床吃早餐、下午茶吃的太饱而错过晚餐，此时再服药自然会错过最佳疗效，这是理所应当的，而不是反过头来认为“早晚餐后服药”的做法是问题。如果你希望得到完整的 ARI 支持，你可以开一个新的 Feature Request。但短期内没有计划实施，因为 ARI 要求使用更频繁地客户端检查（即以限制及开销更小的检查流程，来取代限制及开销更大的签发流程），与目前工作流的执行模式并不完全匹配。此外，目前只有 LE 支持 ARI、其余诸如 GTS、ZeroSSL 等 CA 虽然端点中名义上包含 `renewalInfo`，但其速率限制与此无关（关于速率的部分本身并不是 RFC 规范内的，LE 的做法只是某种副产物），专为特定 CA 提供支持在我看来并不迫切。在有好的实施方案、或更紧迫的时间表之前，我不会贸然行动。

kerem commented

2026-03-03 01:05:40 +03:00

Author

Owner

@xlionjuan commented on GitHub (Dec 9, 2025):

沒有什麼好貿然行動的，標準規範就擺在那邊，而且其實 ARI 這東西早就講非常久了，以後是肯定要實施的，就請你納入到 milestone，LE 官方都這麼說了，還被你說成這樣，還用吃飯時間這種嚴重錯誤的比喻我也是醉了，ARI 本來就是讓 WebPKI 行業更安全更強健的一個修訂功能，抱怨實施難度無傷大雅，但如果還自大的認為不遵循行業規範是理所應當，那其它我就不再說了。

@xlionjuan commented on GitHub (Dec 9, 2025): 沒有什麼好貿然行動的，標準規範就擺在那邊，而且其實 ARI 這東西早就講非常久了，以後是肯定要實施的，就請你納入到 milestone，LE 官方都這麼說了，還被你說成這樣，還用吃飯時間這種嚴重錯誤的比喻我也是醉了，ARI 本來就是讓 WebPKI 行業更安全更強健的一個修訂功能，抱怨實施難度無傷大雅，但如果還自大的認為不遵循行業規範是理所應當，那其它我就不再說了。

kerem commented

2026-03-03 01:05:40 +03:00

Author

Owner

@fudiwei commented on GitHub (Dec 9, 2025):

沒有什麼好貿然行動的，標準規範就擺在那邊，而且其實 ARI 這東西早就講非常久了，以後是肯定要實施的，就請你納入到 milestone，LE 官方都這麼說了，還被你說成這樣，還用吃飯時間這種嚴重錯誤的比喻我也是醉了，ARI 本來就是讓 WebPKI 行業更安全更強健的一個修訂功能，抱怨實施難度無傷大雅，但如果還自大的認為不遵循行業規範是理所應當，那其它我就不再說了。

曲解和攻击姿态不会对议题推进有任何帮助 😄

@fudiwei commented on GitHub (Dec 9, 2025): > 沒有什麼好貿然行動的，標準規範就擺在那邊，而且其實 ARI 這東西早就講非常久了，以後是肯定要實施的，就請你納入到 milestone，LE 官方都這麼說了，還被你說成這樣，還用吃飯時間這種嚴重錯誤的比喻我也是醉了，ARI 本來就是讓 WebPKI 行業更安全更強健的一個修訂功能，抱怨實施難度無傷大雅，但如果還自大的認為不遵循行業規範是理所應當，那其它我就不再說了。曲解和攻击姿态不会对议题推进有任何帮助 😄

kerem commented

2026-03-03 01:05:40 +03:00

Author

Owner

@ZeroClover commented on GitHub (Dec 9, 2025):

在开源项目这样说是没有任何意义的，你可以 PR 或者 Fork

我提到的链接和 Short-lived 无关，只是单纯测试了 CertID 和速率限制的关系

但是，由于 ARI 驱动的续期目前没有实现，那个禁用 ARI 续期的开关在上下文中也根本没有被引用，所以也许应该移除该开关或者添加说明文本以免造成误解

@ZeroClover commented on GitHub (Dec 9, 2025): 在开源项目这样说是没有任何意义的，你可以 PR 或者 Fork 我提到的链接和 Short-lived 无关，只是单纯测试了 CertID 和速率限制的关系但是，由于 ARI 驱动的续期目前没有实现，那个禁用 ARI 续期的开关在上下文中也根本没有被引用，所以也许应该移除该开关或者添加说明文本以免造成误解

kerem commented

2026-03-03 01:05:40 +03:00

Author

Owner

@fudiwei commented on GitHub (Dec 9, 2025):

我提到的链接和 Short-lived 无关，只是单纯测试了 CertID 和速率限制的关系

Issue 原文中使用了 short-lived。short-lived 会使窗口期发生变化，进而 Certimate 在默认配置不会落在窗口期内；但非 short-lived 时使用默认配置一定在窗口期内。

那个禁用 ARI 续期的开关在上下文中也根本没有被引用

感谢反馈，这是一个在重构代码时因拼写错误而丢失的配置，将在后续版本修复。

@fudiwei commented on GitHub (Dec 9, 2025): > 我提到的链接和 Short-lived 无关，只是单纯测试了 CertID 和速率限制的关系 Issue 原文中使用了 short-lived。short-lived 会使窗口期发生变化，进而 Certimate 在默认配置不会落在窗口期内；但非 short-lived 时使用默认配置一定在窗口期内。 > 那个禁用 ARI 续期的开关在上下文中也根本没有被引用感谢反馈，这是一个在重构代码时因拼写错误而丢失的配置，将在后续版本修复。

Rows
Columns

[GH-ISSUE #1094] [Bug] Let's Encrypt Staging ARI didn't used #739

Release Version / 软件版本

Description / 缺陷描述

Steps to reproduce / 复现步骤

Logs / 日志

Miscellaneous / 其他

Contribution / 贡献代码