httpd-bugs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45922] New: Expand the conditions under which "SSLVerifyClient optional_no_ca" works
Date Tue, 30 Sep 2008 18:06:18 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45922

           Summary: Expand the conditions under which "SSLVerifyClient
                    optional_no_ca" works
           Product: Apache httpd-2
           Version: 2.2-HEAD
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: mod_ssl
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: cantor.2@osu.edu


The various processing steps that take place when mod_ssl evaluates a client
certificate are rather unclear when optional_no_ca is used. In particular,
certain conditions that shouldn't cause a problem still fail the request, such
as limitations on "depth" of the chain, an expired certificate, or an inability
to find an intermediate CA that issued the client's certificate.

(Various versions of Apache/mod_ssl have different behavior, so some of those
limitations may be corrected now.)

But in most cases, what's desired by "no_ca" is for mod_ssl to get out of the
way. We have applications that need to make their own rules, and may not be
relying on any kind of traditional certificate evaluation at all.

My suggestion is that instead of treating only a limited number of "error"
conditions as "ignorable", using the ssl_verify_error_is_optional() macro, that
this be removed as a criteria.

Other changes may also be needed to eliminate other non-error conditions from
stopping the connection.

The only real requirement mod_ssl should have is that OpenSSL knows the peer
used the private key corresponding to the certificate, which I believe is
implicit in the API. All of the certificate content should be ignorable.

Basically, no_ca should mean no_ca, not "some things are ok, but not others".
If this is deemed a change to the behavior, then adding a new value for
SSLVerifyClient would also be a reasonable way to address it, perhaps something
called "optional_accept".

But I think as it stands that the no_ca option is a bit ill-defined, and my
project (Shibboleth) has been seeing a lot of anomalous results using it.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org


Mime
View raw message