Dear Buypass Team,

We are integrating your ACME renewal-info endpoint into our system and have encountered a minor discrepancy. Our implementation, which follows the ACME ARI draft, expects that the response will include a Retry-After header. However, our tests indicate that the response contains a "retryAfter" field only in the JSON body, and no Retry-After header is returned.

A reading of the ACME ARI specification indicates that the Retry-After value SHOULD be provided as an HTTP header.

Below is a sanitized version of our test output (with sensitive values replaced by placeholders):

$ curl -v https://api.buypass.com/acme/renewal-info/<CERT_ID>
*   Trying 185.62.162.162:443...
* Connected to api.buypass.com (185.62.162.162) port 443 (#0)
* TLS handshake completed, using TLSv1.2
> GET /acme/renewal-info/<CERT_ID> HTTP/1.1
> Host: api.buypass.com
> User-Agent: curl/7.88.1
> Accept: */*
>
< HTTP/1.1 200 OK
< Content-Length: 133
< Content-Type: application/json;charset=UTF-8
< Date: Wed, 02 Apr 2025 11:57:21 GMT
< Strict-Transport-Security: max-age=63072000
<
{"contentType":"application/json","retryAfter":21600,"suggestedWindow":{"start":"2025-07-30T23:59:00Z","end":"2025-09-28T23:59:00Z"}}

For example, our reading of the ACME ARI specification (see below) indicates that the response should be structured as follows:

HTTP/1.1 200 OK
Content-Type: application/json
Retry-After: 21600

{
  "suggestedWindow": {
    "start": "2025-01-02T04:00:00Z",
    "end": "2025-01-03T04:00:00Z"
  },
  "explanationURL": "https://acme.example.com/docs/ari"
}

Could you please look into this behavior and let us know if it is intentional or if it might be addressed in a future update? Any guidance or clarification you can provide would be greatly appreciated.

Thank you very much for your time and support.

Thank you for your support.

Sincerely,

Ivar