fall back to CRL if OCSP check fails #1692

alanbuxey opened this Issue Aug 27, 2016 · 0 comments


None yet

2 participants



investigating using CRL if the OCSP check fails - rather than doing both CRL AND OCSP for each case.

the server, as default...has a 'check CRL' option in EAP
module config....and an ocsp {} section...... now, looks to me like the check CRL
is a hardcoded function in the system and I cannot so

ocsp {

if (some flag that lets me know OCSP has soft failed) {

ie so OCSP first...and ONLY if theres a soft fail - OCSP responder didnt respond...THEN
fall to using CRL mechanism...as belts and braces.

had a chat with Arran, reply was

"In the interest of everyones sanity and to get rid of the decades of mangled hacks, my idea would be to expose the OCSP checks as a separate module, and get rid of all the softfail stuff…

So you have the TLS verify callback add &request:TLS-CRL-Result := , before calling the virtual server, then in the virtual server:

tis-verify {
if (fail) {
crl_check # Translates &request:TLS-CRL-Result to an rcode (could just be an unlang policy)

We could also get rid of all the verify command stuff as well.

I’ve discussed with Alan D, and we’ve agreed the best way to implement logic moving forward is with virtual server sections, so this fits quite well with that."

so adding this as a server enhancement request,


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment