ARI endpoint change announcement?

[rmbolger]

It looks like the ARI endpoint in the renewalInfo field of the directory object changed in Prod and Staging relatively recently.

Old
https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo
New
https://acme-v02.api.letsencrypt.org/acme/renewalInfo

Was there an announcement about this that I missed?

My client apparently doesn't refresh the directory endpoint data very often (a deficiency I'll be fixing) and started getting 404 errors for ARI requests against the old endpoint.

[jvanasco]

My client apparently doesn't refresh the directory endpoint data very often (a deficiency I'll be fixing) and started getting 404 errors for ARI requests against the old endpoint.

Thanks for posting this.

FYI, something that has long irked me, is the random key entry, e.g.

>   "9B3FY1eAFU0": "https://community.letsencrypt.org/t/adding-random-entries-to-the-directory/33417",

To get around that, I maintain a list of safe keys to track:

src/peter_sslers/lib/acme_v2.py

I thought about eliminating the key by value, but other CAs might implement something similar, so I ended up maintaining a list of safe keys for comparison.

Among other things, I use the cached data to validate profiles before submission.

[petercooperjr]

I didn't see any announcement, though I was wondering when they were going to finally stop putting "draft" in their URLs.

Their directory endpoint (currently, at least) sends Cache-Control: public, max-age=0, no-cache so I think their intention (and per the various specs) is that they expect the directory to be checked each and every time for everything. Though that does seem rather inefficient.

If they're not going to post an API announcement for removing the account creation ip from the account response, removing the contact info from the account response, or changing the API endpoint from RSA to ECDSA, I wouldn't expect an announcement for this.

[Osiris]

@rmbolger

Was there an announcement about this that I missed?

It has reached RFC status.

@petercooperjr

If they're not going to post an API announcement for removing the account creation ip from the account response, removing the contact info from the account response, or changing the API endpoint from RSA to ECDSA, I wouldn't expect an announcement for this.

Why would they? The renewalInfo key is just the same. The fact the value is different should not matter at all. Nothing should break, everything should just keep working. It's not an API change. Why bother mentioning it?

[samlh]

Just for reference, the change was made in this commit:

RFC 9773: Update ARI URL (#8274)

[petercooperjr]

That's kind of what I was saying, that if they're not making announcements for things that are definitely changes, they wouldn't for this where clients shouldn't notice.

Though one would think that returning "pending" from an order finalization request wouldn't break anything either, but apparently that breaks enough things that they don't plan on actually doing it.

[aarongable]

@Osiris

Why would they? The renewalInfo key is just the same. The fact the value is different should not matter at all.

Yep! We purposefully didn't announce this one, because it shouldn't break anyone.

@jvanasco

To get around that, I maintain a list of safe keys to track:

As long as you only use this for change detection, and not anything load-bearing, go for it! Just be careful, as this kind of hard-coding of the expected keys is just one step away from exactly what the random key is meant to prevent.

[jvanasco]

@aarongable

As long as you only use this for change detection, and not anything load-bearing, go for it! Just be careful, as this kind of hard-coding of the expected keys is just one step away from exactly what the random key is meant to prevent.

I admittedly play things a bit dangerous, and cached the directory for 5 minutes during batch operations. The client runs hourly - so the cache will expire in time for the Subscriber to not notice. I did drop that down to 1 minute after this API change, so it aligns with a feature I'm prototyping – pausing operations against a server (and sending an alert) if there are more than 5 connectivity issues in a 1 minute period.

The change detection is used to trigger alerts about API changes. I originally only tracked the meta field to catch profile changes, but I wanted to detect endpoint changes to correlate errors to during post-mortem incident audits. Not all ACME Servers provide a /build endpoint like Boulder, and not all CAs publish API Announcements as accessibly as ISRG, so being able to reference these is incredibly useful.