Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
NSS OCSP Brainstorming: Difference between revisions
Jump to navigation
Jump to search
→NSS' internal OCSP Cache
mNo edit summary |
|||
| Line 38: | Line 38: | ||
However, some CAs use next-update values of weeks or months. Because of that NSS uses an upper boundary to define whether a cached response is fresh or not. As of NSS version 3.11.7 the upper boundary is 24 hours. | However, some CAs use next-update values of weeks or months. Because of that NSS uses an upper boundary to define whether a cached response is fresh or not. As of NSS version 3.11.7 the upper boundary is 24 hours. | ||
<blockquote><i> | |||
As is pointed out below, this behaviour might be problematic in strict mode. If a CA decides to produce new responses every 48 hours, they will set the cache control headers on the HTTP response containing the OCSP response appropriately. This will mean an intermediate cache is perfectly allowed to hold on to the response for 48 hours, and so checks will start failing after the upper boundary (24 hours) is reached. - Gerv | |||
</i></blockquote> | |||
Once NSS considers a cached OCSP response to be no longer fresh, it will attempt to obtain a new response. In relaxed mode, NSS will ignore failures. However, in strict mode, NSS will require to obtain a new valid response or reject the cert as invalid. | Once NSS considers a cached OCSP response to be no longer fresh, it will attempt to obtain a new response. In relaxed mode, NSS will ignore failures. However, in strict mode, NSS will require to obtain a new valid response or reject the cert as invalid. | ||