How long is a certificate available for download?

Client dev
1

after the finalize step, how long is it available for download/re-download in boulder?

the acme spec is silent to this.

there’s a small edge-case on our client where the certificate doesn’t get saved correctly. it seems I can just re-download it “immediately” as a short-term solution.

1 Like
2

Hi @jvanasco

there is a long time possible. The download address is fixed:

https://acme-v02.api.letsencrypt.org/acme/cert/ + SerialNumber

Tested with my last certificate, created 2019-12-22 (must renew :wink: ):

https://acme-v02.api.letsencrypt.org/acme/cert/038CE3E3E956B9AEDAE7EAF00C18B4F7D821

It's possible to download the certificate.

3 Likes
3

Sorry I should have been more specific. I meant the url provided in “certificate” on the AcmeOrder object, which is downloaded via the get-as-post method.

Your endpoint still being in the system is promising to me - however I will not have the certificate serial.

In my use-case, the acme server receives the finalize command and we have possibly downloaded the certificate… however an application error causes the local copy to not be correctly saved.

To handle this I load the order url and try to download and process the certificate. It works, but I’d like to know if it is reliable.

1 Like
4

They do seem to delete orders, I have a few from 2018 which are now 404.

The Boulder janitor has its deletion grace period set to 91 days, but who knows if that’s what is actually set in production.

I think it’s probably pretty safe to assume that the order won’t disappear within the validity period of the certificate.

2 Likes
5

Ok, if the default is set to 91 days and anecdotally people have seen orders around for more than a week - potentially years - it seems like I can keep my functionality as a public API / documented feature. Realistically I don’t think one needs more than 24 hours to “fix” an order.

1 Like
6

Checked the log, that's the same url.

{
"status": "valid",
"expires": "2019-12-29T21:59:40Z",
"identifiers": [
{
"type": "dns",
"value": "*.server-daten.de"
},
{
"type": "dns",
"value": "server-daten.de"
}
],
"authorizations": [
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/1874305092",
"https://acme-v02.api.letsencrypt.org/acme/authz-v3/1874462362"
],
"finalize": "https://acme-v02.api.letsencrypt.org/acme/finalize/35657966/1824846879",
"certificate": "https://acme-v02.api.letsencrypt.org/acme/cert/038ce3e3e956b9aedae7eaf00c18b4f7d821"
}

The certificate uses the new serial number. And the order is expired, but the download works.

2 Likes
7

Interesting. I assumed it wasn’t because I could download your certificate, and that is supposed to be an authenticated POST-as-GET resource – not a simple GET.

Looking at the Boulder Divergences doc, it seems GET will be allowed until this November, which is why it works.

1 Like
8

I dunno about this. I don't have any concrete examples at the moment, but I vaguely recall having orders purged prior to the associated certificate's expiration before. There was a bug in my client that assumed it would be able to refresh the server's view of the order details prior to renewal that didn't work because it was getting effectively a 404. I'd probably amend this statement to the expiration of the order object instead.

2 Likes
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.