New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fall back to CRL if OCSP check fails #1692

alanbuxey opened this Issue Aug 27, 2016 · 0 comments


None yet
2 participants

alanbuxey commented Aug 27, 2016


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 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