hanhaka
commented
8 years ago Additional information regarding issue (by Petteri):
The problem with the current implementation is that not every OCSP response is refreshed ocspFreshnessSecons / 10. Only OCSP responses that are about to expire within the defined timeframe are refreshed. For example:
ocspFreshnessSeconds = 7200 s (2 h) ocspFreshnessSeconds / 10 = 720 s (12 min) now = 2016-07-06 21:11:17 allowedThisUpdate = (now + ocspFreshnessSeconds / 10) - ocspFreshnessSeconds = 2016-07-06 19:23:17 isExpired = thisUpdate < allowedThisUpdate
Signer runs every 12 minutes and checks all the OCSP responses. If and only if isExpired is true, the OCSP response is refreshed. This means that the OCSP response is not refreshed until it’s thisUpdate value is older than 6480 seconds. If refreshing the OCSP response fails, it will expire as signer will try again after 12 minutes when it’s already too late as ocspFreshenessSeconds has been exceeded. Implementing issue 64 will fix this problem.
Affected components: signer, global configuration Affected documentation: - Estimated delivery: - External reference: https://jira.csc.fi/browse/PVAYLADEV-460
Problem Currently signer is preset to work using the polling time: ocspFreshnessSecons/10 for the OCSP responses. So the new OCSP response will be fetched just before the old OCSP response is close to its expiration. If the OCSP service is breaking or malfunction situation realizes, it leads to the situation that the Security Servers which did the fetching of the OCSP responses just before failure are fine, but the other Security Servers trying to fetch the responses right after the failure, are bad. Because every Security Server has its own phase to fetch the OCSP responses, it is impossible to foresee which Security Servers are going down and which are not if the OCSP service goes down.
This dilemma could be remarkable improved so that the OCSP responses would be fetched from the OCSP service same way as the Global Configuration update process is working at the moment: Global Configuration is fetched once in every minute and it (=configuration) is valid as long as it is defined to be valid in configuration (normally 72hours). By acting in this way the Security Server has always the fresh Global Configuration in use and Security Server can operate up to 71hours 58 minutes even if the OCSP service is out-of-order. The interval for fetching the OCSP response could be something like 1 hour - more often than that is useless since the Certification revocation list is updated once in an hour.
Acceptance criteria