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: [email protected]
ReportedBy: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
