Can ARI send a notification with callback URL when a certificate is about to expire unexpectedly or outside the planned schedule?

[aarongable]

Hi folks, I've been OOO. Thanks for the discussion so far.

@Dongwang

Given that we may manage up to 640k certificates, periodically querying each domain isn't practical.

What do you do to check if any of those 640k certificates have been revoked? Historically, you should be checking OCSP for each of these certs on a regular basis. Adding a simultaneous ARI check should be reasonably straightforward. If you haven't been checking for revocation, now is a good time to start

That said, I hear this complaint. You aren't the first person to ask for a more efficient way to check the ARI status of large numbers of certificates. But none of the methods proposed so far (including callbacks: you don't want your server to receive 640k simultaneous webhook requests when we have a mass revocation incident) have been reasonably practicable.

[Dongwang]

As a developer, I’m not entirely familiar with this process—it seems like we mainly check the emails.

I don’t believe handling 640k simultaneous requests is ideal. With polling, we continuously send 640k requests within each time window, which could overwhelm the system. On the other hand, using callbacks can also complete 640k requests within a time window, but with more control and potentially less resource strain.

[mholt]

@aarongable

you don't want your server to receive 640k simultaneous webhook requests when we have a mass revocation incident) have been reasonably practicable.

I'm not necessarily advocating for callbacks, but what about 1 callback that enumerates all the ARI updates for that account?

[aarongable]

@Dongwang

With polling, we continuously send 640k requests within each time window, which could overwhelm the system. On the other hand, using callbacks can also complete 640k requests within a time window, but with more control and potentially less resource strain.

I'm afraid I don't understand. If you were constantly polling ARI at the fastest suggested rate (one query every 6 hours for each certificate), your systems would produce a steady rate of about 30 queries per second. Is 30 outbound queries (which can reuse the same HTTP/2 stream, so no need to do a handshake for each of them) every second going to overwhelm your systems?

Contrast with the proposed callback, where in the worst case we would produce 640k requests to your callback endpoint within a single second, which is obiviously not going to be a good time for anyone.

[petercooperjr]

@mholt

I'm not necessarily advocating for callbacks, but what about 1 callback that enumerates all the ARI updates for that account?

Well, even with polling-based ARI, one could imagine some would find helpful having an endpoint that gave the status for all certificates for an account (maybe just a list of what certs are renew-now rather than a suggested window for each, so that it usually isn't a big response). But I suspect Let's Encrypt wouldn't prefer that as much for the same reason they don't implement listing all existing orders for an account: it would get a lot of data from across multiple certificates, and it's much easier for them to just give separate endpoints for each cert backed by their CDN.

[mholt]

@petercooperjr

Well, even with polling-based ARI, one could imagine some would find helpful having an endpoint that gave the status for all certificates for an account (maybe just a list of what certs are renew-now rather than a suggested window for each, so that it usually isn't a big response)

Yep! Indeed that's something I've advocated for before.

But, I've implemented it the other way now so it's a moot point IMO. It is what it is.

[Dongwang]

What I mean is that callbacks don't need to be sent all at once within a single second; they can be scheduled and staggered over a 6-hour period.

[Dongwang]

That's a good suggestion.

[Dongwang]

After exploring the renewalInfo API, I found that the current implementation requires renewalInfo resources to be exposed and accessible via unauthenticated GET requests. Additionally, since the service is backed by a CDN, performance is no longer a concern. Polling the API—even for millions of renewals—will not pose any challenges. Thank you all for your patience and support throughout this process.