DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=35083>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=35083 [EMAIL PROTECTED] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WONTFIX | ------- Additional Comments From [EMAIL PROTECTED] 2005-08-31 09:31 ------- Joe, 1. I do not think we could blame the browsers (at least not totally), because they do not receive enough information to display a error complete mesage. 2. Although Apache strictly follows the standards, its main goal is to be used by B2B-like clients, AND BROWSERS, no ? There is no one browser that implements SSL error trapping in another way that giving a technical error message or number 3. In a lot of environments, the Web admin would like to give more information to the user about how to solve the connection problem. This is especially true in governmental sites: most of European countries (and several other ones) are deploying identity smart card with national certificates that are intended to bare citizens that do not understand anything about certificates. The error message to be given is highly specific in this case. 4. Although not stressed in the module description, the module also allows some reporting of errors in a way governmental applications like a lot: their application can receive (and so handle/log) any connection failure with the exact reason. Again, for governmental certificates, this is highly important because of the OCSP SLA, etc. This could be achieved in a separate application/script by analysing the logs, although the needed log level would probably generate to much data for a production environment. > If you do want custom HTML responses for cert validation problems, it should > be possible already using "SSLVerifyClient optional" with SSLRequire and > a custom 403 errordoc. > What about the current code prevents that? > Possibly more information needs to be exported to get to the > "certificate has expired" stuff. > 2.1's SSL_CLIENT_V_REMAIN might be sufficient for that. I tried, but couldn't do that (at least in 2.0.54). Revoked certificates are accepted and ther's no way to trap it. If we could trap the errors without modifying med_ssl core, then it's obviously perfect. My module could thus be reimplemented to use that new SSL_CLIENT_V_REMAIN, is that correct ? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
