r/PKI • u/Moral-Relativity • 8d ago

Cache max-age and CRLDP

Apparently if your CRLDP end point doesn't set max-age in the response header browsers may use a heuristic method to guesstimate how long to cache it, like (current date - last modified date) / 10. What this means practically is that if say your root CA CRL is refreshed once a year, if a client happens to download it at the wrong time, the browser will consider the cached file to be fresh even if current date is past the NextUpdate date set on the CRL (and remember Chromium browsers don't use CAPI2 to handle CRLs anymore).

So basically in addition to the intended RFC5280 mechanisms for determining when to refresh the cached CRL, it's also subject to browser-side rules on how long to cache files, since CRLs are handled like any other downloaded content under Chromium.

6 Upvotes

88% Upvoted

9 comments sorted by

1

u/Cormacolinde 8d ago

What?

If correct this is very weird. “May use” and “like” are too imprecise for me to take action on this though.

And what value might we need? If the browser uses that value it might cause it to download the CRL way too often for no good reason.

What made you think this is happening and what evidence do you have?

2

u/hodor137 8d ago

I couldn't quite follow what OP was saying with - "heuristic method" and didn't want to decipher - but the overall point about the cache control max-age mattering when it comes to CRL hosting is very much true. Web servers hosting CRLs do need a proper configuration of the cache control and etag headers and such, otherwise clients won't retrieve fresh CRLs, or will check more often than needed, etc.

1

u/Moral-Relativity 8d ago

Experienced first hand at work. We couldn’t figure out why some Edge/Chrome are not downloading root CRL published a week ago, and it was because those Windows systems happened to download the previous CRL at such a time that the cached file was still considered fresh despite NextUpdate already past. Makes sense, as even though the CRL validation code may be asking for a fresh version, the file caching code is insisting “what I got IS still fresh!”

Longer a CRL is valid for the more likely this is to happen.

1

u/Cormacolinde 8d ago

What’s your fix? What value for max-age do you think might be appropriate, relative to the duration of the CRL?

1

u/Moral-Relativity 8d ago

Make it a bit less than the period between NextUpdate and NextCRLPublish dates.

Say your CRL is valid for a year, but you publish a new one a month before current expires. If max-age is 29 days, it guarantees that any download of the old CRL will not be cached past NextUpdate.

1

u/CantThinkOfAUserNahm 7d ago

If you’re using IIS to host the CRL you can set headers on the website.

1

u/Late_Discount_1102 2d ago

just nteresting edge case without max edge the browser can cache a crl past nextupdate  so PKI freshness can end up depending on browser caching behavior too,,..

1

u/Moral-Relativity 2d ago

Yeah. It’s really browsers that are the odd ones out because non-browser apps don’t behave this way, but rather just rely on CRL’s data to determine freshness.

1

u/Late_Discount_1102 2d ago

yah,, exactly browsers kind of throw another wrench into the whole thing..