httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Kraemer <mar...@apache.org>
Subject Re: [PATCH] ssl_ext_lookup #2
Date Tue, 20 Sep 2005 14:08:18 GMT
On Thu, Sep 15, 2005 at 04:30:50PM +0100, Joe Orton wrote:
> 
> Can we just back out the mod_setenvif stuff from the trunk or is someone 
> going to make it work BTW?

Uhm. Strange. Back at the 'Con, I tested my committed changes with a
configuration like:
 SetEnvIf OID("2.16.840.1.113730.1.13") "(TinyCA) Generated (Certificate)" Yes_this_certificate_is_from_TinyCA=$1_$2
 SetEnvIf OID("1.16.840.1.113730.1.13") "TinyCA Generated Certificate" FooBarFalse=$1
and the SSL check:
 SSLRequire "TinyCA Generated Certificate" in OID("2.16.840.1.113730.1.13") \
         || "committers"                   in OID("1.3.6.1.4.1.18060.1")
and had a .shtml file which contained:
--snip-- htdocs/ssi.shtml:
<pre>
<!--#exec cmd="echo $Yes_this_certificate_is_from_TinyCA|figlet -funivers" --><!--#printenv
-->
--snip--

After the various changes made in the meantime, I now changed it to
 SetEnvIf SSL_PeerExtList("2.16.840.1.113730.1.13") "(TinyCA) Generated (Certificate)" Yes_this_certificate_is_from_TinyCA=$1_$2
 SetEnvIf SSL_PeerExtList("1.16.840.1.113730.1.13") "TinyCA Generated Certificate" FooBarFalse=$1
 SSLRequire "TinyCA Generated Certificate" in PeerExtList("2.16.840.1.113730.1.13") \
         || "committers"                   in PeerExtList("1.3.6.1.4.1.18060.1")

The SSLRequire works still: if I (supply a client cert and) access the
server with a client cert that has a NSComment
 "TinyCA Generated Certificate"
then I get access, but if I change the string or the OID to something
different, I get a [403] page.

But the mod_setenvif code -as it is in svn- does not work any
longer. The variable ${Yes_this_certificate_is_from_TinyCA}
is no longer set in the server environment (but used to be
in july).

So, I changed it to my old patch plus recent updates (attached)
and retested it with:
--snip-- httpd.conf:
<Directory "/usr/local/apache2/cgi-bin">
    Options None
    Order allow,deny
    Deny from all
</Directory>
--snip--

--snip-- httpd-ssl.conf:
<VirtualHost _default_:8443>
LogLevel info
...
SSLVerifyClient require
SSLVerifyDepth  10
<Location />
SSLRequire "TinyCA Generated Certificate" in PeerExtList("2.16.840.1.113730.1.13") \
        || "committers"                   in PeerExtList("1.3.6.1.4.1.18060.1")
</Location>
<FilesMatch "\.(cgi|shtml|phtml|php)$">
    SSLOptions +StdEnvVars
</FilesMatch>
<Directory "/usr/local/apache2/cgi-bin">
    SSLOptions +StdEnvVars
    # Do not do this on your production server:
    AllowOverride All
    Deny from all
</Directory>
--snip--

--snip-- /usr/local/apache2/cgi-bin/.htaccess
 order deny,allow
 deny from all
 allow from env=Yes_this_certificate_is_from_TinyCA
--snip--

With this setup, I have no problems denying access when I change
the allow from env= variable name to something different.

But as you say, this should not work, and ATM I am at a loss to
explain why it works here. Do you see a reason why?

   Martin

PS: Also, but that is already under discussion elsewhere (Marc Stern
did very good work in that area), the connection is simply torn down
if the client does NOT provide a client cert or if the certificate
purpose is wrong. I get "The document contains no data" or
"server.dom.ain has received an incorrect or unexpected message. Error
Code: -12227" in the browser (or just as cryptic
"30602:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:226:" in "openssl s_client", and in the best case
  [Tue Sep 20 15:08:48 2005] [error] Certificate Verification: Error (26): unsupported certificate
purpose
in the logs. If the client does not present any cert, nothing at all
is logged in the default log level. When set to "info" level, I see
  [Tue Sep 20 15:12:28 2005] [info] SSL Library Error: 336105671 error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer
did not return a certificate No CAs known to server for verification?
). 
So, all in all, I fully agree that handling SSL errors gracefully is a
very important goal for acceptance (of Apache as SSL server, for Svn
as well as for all the SSL user community out there).
-- 
<Martin.Kraemer@Fujitsu-Siemens.com>         |     Fujitsu Siemens
Fon: +49-89-636-46021, FAX: +49-89-636-48332 | 81730  Munich,  Germany

Mime
View raw message