httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 35083] Certificate validation problems trapping
Date Wed, 09 Nov 2011 14:46:32 GMT

--- Comment #22 from ekp <> 2011-11-09 14:46:32 UTC ---
I have the very same problem with revoked certificates as explained by comment
7: not being able to "trap" SSL errors in order to redirect to some sort of
custom processing is very annoying.

I have a business case where customer's security policy prescribes to log any
failed login attempt and this includes revoked certificates. This can not be

Tested with 2.2.14 on Linux (+ checked 2.2.21 source code of
modules/ssl/ssl_engine_kernel.c: as far as I remember C language, the problem
is still there).

Tried with rewrite rules: doesn't work, connection attempt with revoked
certificate is shutdown by mod_ssl and rules are not evaluated.

RewriteEngine    on
RewriteRule    .? /unsecure/bad-ssl.cgi [R,L]

One alternative would be to run a frontend before Apache, if that frontend is
capable of better handling of SSL errors. Quite a heavy solution (+ more admin
burden)... Another alternative would be to run SSL controls at the application
layer, "after" Apache handles the request to Tomcat or whatever else. This
would be ill-architected.

It would be great to be able to detect SSL errors (not only revoked
certificates, one can think of out-dated CRLs also) in order to redirect those
cases to some custom processing, with rewrite rules for example or whatever
else that is under our responsability, not Apache's code.

Willing to help in order to give "additional information before it can be
dealt", Erik.

PS: "out-dated CRLs" => see 2.2.21 ssl_engine_kernel.c line 2106: from what I
understand (newbie to Apache source code...), if current date is greater than
next update date stored in current CRL then all client certificates are
rejected. This is kind of "brute force" if the admin forgets to update CRL
before the "next update" date stored in the current CRL, or if a cron job
fails, or whatever like this happens...

Configure bugmail:
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message