At this moment, certificate without http scheme as ocsp responder uri, including https can't be verified. This probably following "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" section 7.1.2.2c. This is an excess of caution in my opinion because it implies that ocsp responder may all be under an unsecure http environment. Furthermore rfc6960 says that "Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either Transport Layer Security/Secure Socket Layer (TLS/SSL) or some other lower-layer protocol." This is the line of code that deny the ocsp responder https uri: if (ap_cstr_casecmp(u->scheme, "http") != 0) { ap_log_cerror(APLOG_MARK, APLOG_DEBUG, rv, c, APLOGNO(01920) "cannot handle OCSP responder URI '%s'", s); return NULL; }
Could you explain your use case for https OCSP urls? All public CAs issue only http urls, as far as I know.
Hi Stefan, thanks for the fast reply. Our use case Is a Pki with our certificates and a custom responder that resides inside a https environment. We developed the responder without knowing the http/s limitation. I think theres no possibilities to avoid that check.
To be more clear, we have certificates without any ocps responder uri. We would like to use the apache direttive overrideresponder to set the default responder tò our ocsp responder. Our responder Is inside an https environment, and this cause the problem explained before
Well, I would recommend to strip that https: from your OSCP responder URLs for technical reasons. If you go outside the internet standards, you are on your own. But I do, of course, not know how difficult that is in your organization. As to httpd, the implementation in mod_ssl does not support https URLs in this place. It is not only a matter of changing the check.