https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
--- Comment #25 from Kaspar Brand <[email protected]> --- (In reply to Alex Bligh from comment #24) > In theory it would I presume be possible for the same certificate on one > vhost to use a different set of extra_certs than on another, which in theory > could result in a different value of 'issuer' per vhost, and hence in theory > a different cert_info structure. Is this in practice an issue? For the stapling part, it's not an issue. What stapling_get_issuer() really needs from the issuing CA is its public key (for creating the request's OCSP_CERTID, see RFC 6960 section 4.1.1, "issuerKeyHash"). Even if there are multiple versions of an issuer cert (e.g. with different validities, alternative signature algorithms etc.), the issuerKeyHash will always be the same for all certificates signed by this key (otherwise the signature of the server cert would fail verification). Or put differently, the members of the certinfo structure ("idx", "cid", "uri") for a specific cert only depend on the cert itself and the public key of its issuer, nothing else. v5 is very close I think. These lines in ssl_stapling_init_cert() cinf = apr_hash_get(mc->stapling_cert_info, idx, sizeof(idx)); if (cinf) { /* It's already in the hash. However, it may not have a uri * If not, check we have a force URL */ if (!cinf->uri && !mctx->stapling_force_url) { ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(02218) "ssl_stapling_init_cert: no responder URL"); return 0; } return 1; } can be shortened to if ((cinf = apr_hash_get(mc->stapling_cert_info, idx, sizeof(idx)))) return 1; as the case of cinf already existing in the hash, but cinf->uri being undefined is a "can't happen", really: remember that "idx" is a SHA-1 hash over the full DER encoding of the certificate (which of course includes the OCSP URI in the AIA extension), so unless we have a collision with the DER encoding of two completely distinct certificates (which would also be very bad for the response cache, just as an aisde), it's impossible to reach the situation where "cinf && !cinf->uri" if we already have a hash entry. (Also, note that every log message needs a unique APLOGNO, so we would have to assign a new one if we kept the message.) -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
