https://issues.apache.org/bugzilla/show_bug.cgi?id=54357
--- Comment #28 from Kaspar Brand <[email protected]> --- (In reply to Alex Bligh from comment #26) > 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. I see. You're right, I didn't think of this case. Maybe it would be good to log mctx->sc->vhost_id in the message as well, so that it's easier to identify for which vhost the problem actually exists (we might even consider switching to ssl_log_xerror, which logs more cert details, but this would mean passing in ptemp to ssl_stapling_init_cert). Using the same APLOGNO() for two different places in the codeshould be avoided, i.e. instead of factoring it out, we can just use a new number for the first occurrence (I can deal with this when checking in, just put in APLOGNO() for the time being). > 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. If you have a cert from a publicly-trusted CA, chances are very high that it also includes an OCSP URI, so configuring the SSLStaplingCache and adding "SSLUseStapling on" will turn on stapling (if your cert lacks an OCSP URI, you could at least try to force a "fake" SSLStaplingForceURL and see if it is properly taken into account). Then, openssl s_client and its "-status" option can be used to connect to the server and request a stapled OCSP response (which will be dumped if provided by the server, otherwise you get "OCSP response: no response sent"). I will also give it a try later this week. -- 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]
