Hi Marc,
On Mon, Jan 08, 2007 at 02:15:44PM +0100, Marc Stern - Approach wrote:
> 1. The current idea is to trap validation-related errors, like
> certificate expiration/revocation.
> Shouldn't we also trap negotiation errors, like incompatible
> ciphersuites and protocols between browser and server ?
> Maybe other ones ?
I would not try to solve everything at once; just concentrate on the one
problem of handling verification errors.
> 2. Recommendations are to use one directive to relax the check on
> certificates (or on ciphersuites, ...), and other ones to trap errors by
> checking environment variables and redirect the 403 errors to a specific
> page.
> a. Doesn't this introduce a security risk, in case the check on
> certificates is relaxed and the other directives are not set (or changed) ?
> This is against the principle of secure by installation ...
I don't see a problem here. The proposal was to add a directive to
relax/restrict the set of verification errors which are considered
"acceptable" for an "SSLVerifyClient optional" configuration.
That directive will then control whether or not the 403 is returned.
> b. This solution would redirect all errors to the same page.
> Isn't it better to trap the error and redirect to a specific
> (customisable) page ?
>
> Note that this trapping could be implemented in a separate module.
I'm not sure what else is needed here. It should already be possible to
access the verification error string e.g. from mod_rewrite using
%{SSL:SSL_CLIENT_VERIFY}. I'd guess this could be done during the
handling of the 403 and could allow a rewrite to a custom URI - or is
there something which prevents that?
Regards,
joe
