Confirmed users
563
edits
NSS OCSP Brainstorming: Difference between revisions
Jump to navigation
Jump to search
→NSS' internal OCSP Cache
| Line 36: | Line 36: | ||
This lower limit is used differently in strict mode. If NSS has no information cached at all about a certificate, it will attempt to talk to the OCSP server each time verification for such a certificate is requested. However, once a response could be received, NSS will use the cached information and not talk to the OCSP server until after the lower time boundary. | This lower limit is used differently in strict mode. If NSS has no information cached at all about a certificate, it will attempt to talk to the OCSP server each time verification for such a certificate is requested. However, once a response could be received, NSS will use the cached information and not talk to the OCSP server until after the lower time boundary. | ||
An OCSP response may contain an optional next-update information. A CA or OCSP server can use this to communicate the earliest time where more recent information might be available. In theory, a cached response may be considered fresh until after the next-update time has been reached. | |||
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. | |||
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. | |||
==HTTP POST vs. HTTP GET== | ==HTTP POST vs. HTTP GET== | ||