Scaling the Let's Encrypt rate limits to prepare for a billion active TLS cert
1–3 of 3 posts
Re: Scaling the Let's Encrypt rate limits to prepare for a billion active TLS cert
#2> Conveniently, the difference between the TAT and the current time can then be returned to the subscriber in a Retry-After header, informing their client exactly how long to wait before trying again.
I hope they know to add in a small amount of anti-synchronization randomness to the exactly-calculated “retry-after” delay.
Re: Scaling the Let's Encrypt rate limits to prepare for a billion active TLS cert
#3> Conveniently, the difference between the TAT and the current time can then be returned to the subscriber in a Retry-After header, informing their client exactly how long to wait before trying again. I hope they know to add in a small amount of anti-synchronization randomness to the exactly-calculated “retry-after” delay.
Just before it's returned to the caller: https://github.com/letsencrypt/boulder/blob/0d7ea60b2cb6fa35...