Bug 62112 - Make OCSP more configurable (like CRL)
Summary: Make OCSP more configurable (like CRL)
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.4.29
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2018-02-17 15:44 UTC by Ricardo Martin Camarero
Modified: 2018-03-16 15:46 UTC (History)
2 users (show)

diff file for my differences (7.25 KB, patch)
2018-02-17 15:44 UTC, Ricardo Martin Camarero
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ricardo Martin Camarero 2018-02-17 15:44:03 UTC
Created attachment 35733 [details]
diff file for my differences

The ocsp revocation is much less configurable than the CRL one. The option SSLCARevocationCheck can be configured using the openssl options: none (no CRL revocation), chain (full CRL revocation for the chain) and leaf (only revocation for the last certificate, the user certificate). There is even a tag  no_crl_for_cert_ok that let you configure the revocation to not fail if no CRL is found for the certificate. The OCSP configuration is just on (chain) or off (none). Therefore not all the CRL configurations can be replaced by an OCSP one.

I did a little proof to configure the SSLOCSPEnable just as the SSLCARevocationCheck tag. The idea is the same:

SSLOCSPEnable  on|chain|leaf|none|no flags
               flags: no_ocsp_for_cert_ok

The values on and off are just added for compatibility and they mean chain and none respectively. 

In several situations I found the the OCSP configuration too strict for me and I couldn't configure what the customer wanted with ocsp (usually only leaf check, or just check OCSP if the certificate has the extension for it).

I tested the changes and it seems to work properly. What do you think? Do you think it is useful?

Comment 1 Ricardo Martin Camarero 2018-03-07 11:34:18 UTC

Any comment on this? Is it OK? Useful? Useless?

Comment 2 Stefan Eissing 2018-03-07 11:41:09 UTC
 I am not the export in this part of the code. The patch looks fine, but maybe Rüdiger wants to have a look at it?
Comment 3 roysjosh 2018-03-14 20:57:30 UTC
I have been carrying a much less functional patch than this locally in order to meet company policy with respect to OCSP.  We are unable to implement OCSP without it due to the CA chain in place.  It looks like this patch would work for us.  Please consider merging this.

Ricardo, thanks for the patch!
Comment 4 Ricardo Martin Camarero 2018-03-16 09:43:36 UTC
@roysjosh I thought the change was going to be much more complicated but (in the end) it was just a few lines and it fits clean in the current code. That's why I filed this bugzilla. Thanks to you for using/testing it.
Comment 5 jeff.baranski 2018-03-16 12:56:13 UTC

I ran into this issue as well. I have a situation where client certs are always setup with an OCSP responder but the intermediates are NOT setup with OCSP responders.

We need a way to say validate just the client cert against the OCSP responder.

Basically I need this patch too.
Comment 6 Stefan Eissing 2018-03-16 15:26:48 UTC
Thanks for the patch. I slightly modified it for trunk and removed the "chain/none", as this is the "on|off" behaviour and there are already enough
options in mod_ssl.

Submitted into trunk as r1826995. Will propose for backport into 2.4.x
Comment 7 Ricardo Martin Camarero 2018-03-16 15:43:24 UTC
Thanks! But take care with this:


Your really setting "on|leaf|none", change the "none" for "off" in the first if.

Comment 8 Stefan Eissing 2018-03-16 15:46:54 UTC
Arg, thanks for the catch! Fixed in r1827001 (I hope!)