When an OCSP responder is down for an extended period, the OCSP refresh cycle'is retry time grows pretty long, because of the current Fibonacci logic. So when the OCSP responder starts working again, it takes too much time for security servers to refresh their certificates' OCSP status.
We propose implementing a sort of max_ocsp_retry_delay parameter that's configurable and can be set to a more acceptable timeframe.
Acceptance criteria
OCSP refresh cycle's max delay is made configurable
Affected components: - xroad-signer Affected documentation: - ug-sysparams Estimated delivery: - N/A External reference: - https://jira.ria.ee/browse/XTE-402
Problem
When an OCSP responder is down for an extended period, the OCSP refresh cycle'is retry time grows pretty long, because of the current Fibonacci logic. So when the OCSP responder starts working again, it takes too much time for security servers to refresh their certificates' OCSP status.
We propose implementing a sort of max_ocsp_retry_delay parameter that's configurable and can be set to a more acceptable timeframe.
Acceptance criteria