| 213 | } |
| 214 | |
| 215 | apr_status_t md_ocsp_start_watching(md_mod_conf_t *mc, server_rec *s, apr_pool_t *p) |
| 216 | { |
| 217 | apr_allocator_t *allocator; |
| 218 | md_ocsp_ctx_t *octx; |
| 219 | apr_pool_t *octxp; |
| 220 | apr_status_t rv; |
| 221 | |
| 222 | wd_get_instance = APR_RETRIEVE_OPTIONAL_FN(ap_watchdog_get_instance); |
| 223 | wd_register_callback = APR_RETRIEVE_OPTIONAL_FN(ap_watchdog_register_callback); |
| 224 | wd_set_interval = APR_RETRIEVE_OPTIONAL_FN(ap_watchdog_set_callback_interval); |
| 225 | |
| 226 | if (!wd_get_instance || !wd_register_callback || !wd_set_interval) { |
| 227 | ap_log_error(APLOG_MARK, APLOG_CRIT, 0, s, APLOGNO(10201) |
| 228 | "mod_watchdog is required for OCSP stapling"); |
| 229 | return APR_EGENERAL; |
| 230 | } |
| 231 | |
| 232 | /* We want our own pool with own allocator to keep data across watchdog invocations. |
| 233 | * Since we'll run in a single watchdog thread, using our own allocator will prevent |
| 234 | * any confusion in the parent pool. */ |
| 235 | apr_allocator_create(&allocator); |
| 236 | apr_allocator_max_free_set(allocator, 1); |
| 237 | rv = apr_pool_create_ex(&octxp, p, NULL, allocator); |
| 238 | if (rv != APR_SUCCESS) { |
| 239 | ap_log_error(APLOG_MARK, APLOG_ERR, rv, s, APLOGNO(10205) "md_ocsp_watchdog: create pool"); |
| 240 | return rv; |
| 241 | } |
| 242 | apr_allocator_owner_set(allocator, octxp); |
| 243 | apr_pool_tag(octxp, "md_ocsp_watchdog"); |
| 244 | |
| 245 | octx = apr_pcalloc(octxp, sizeof(*octx)); |
| 246 | octx->p = octxp; |
| 247 | octx->s = s; |
| 248 | octx->mc = mc; |
| 249 | |
| 250 | /* Time for some house keeping, before the server goes live (again): |
| 251 | * - we store OCSP responses for each certificate individually by its SHA-1 id |
| 252 | * - this means, as long as certificate do not change, the number of response |
| 253 | * files remains stable. |
| 254 | * - But when a certificate changes (is replaced), the response is obsolete |
| 255 | * - we do not get notified when a certificate is no longer used. An admin |
| 256 | * might just reconfigure or change the content of a file (backup/restore etc.) |
| 257 | * - also, certificates might be added by some openssl config commands or other |
| 258 | * modules that we do not immediately see right at startup. We cannot assume |
| 259 | * that any OCSP response we cannot relate to a certificate RIGHT NOW, is no |
| 260 | * longer needed. |
| 261 | * - since the response files are relatively small, we have no problem with |
| 262 | * keeping them around for a while. We just do not want an ever growing store. |
| 263 | * - The simplest and effective way seems to be to just remove files older |
| 264 | * a certain amount of time. Take a 7 day default and let the admin configure |
| 265 | * it for very special setups. |
| 266 | */ |
| 267 | ocsp_remove_old_responses(mc, octx->p); |
| 268 | |
| 269 | rv = wd_get_instance(&octx->watchdog, MD_OCSP_WATCHDOG_NAME, 0, 1, octx->p); |
| 270 | if (APR_SUCCESS != rv) { |
| 271 | ap_log_error(APLOG_MARK, APLOG_CRIT, rv, s, APLOGNO(10202) |
| 272 | "create md ocsp watchdog(%s)", MD_OCSP_WATCHDOG_NAME); |
no test coverage detected