https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
--- Comment #26 from Alex Bligh <[email protected]> --- > 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: I think you might be wrong about that. Let's say two vhosts have the same certificate. The first vhost this comes across calls ssl_stapling_init_cert, and this calls X509_get1_ocsp. X509_get1_ocsp reveals this certificate has no URI, however on this vhost, SSLStaplingForceURL is set at a vhost level. The certificate's info then gets added to the hash. The second vhost then gets processed. The SHA is the same (obviously) so what the above section does is to check that on the second vhost, SSLStaplingForceURL is also set. If we don't make this check, then on the first vhost will be OK because it has SSLStaplingForceURL set, and the second vhost will be OK although it does not have SSLStaplingForceURL set. That means that when it gets to deal with the stapling for the second vhost, there will be no URL. IE it's purpose is to look for an illegal configuration and return 0 in that case. Someone who knows how to test OCSP should really test this code works as opposed to merely compiles. I have no idea how to do that. -- 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]
