Bug 45922

Summary:	Expand the conditions under which "SSLVerifyClient optional_no_ca" works
Product:	Apache httpd-2	Reporter:	Scott Cantor <cantor.2>
Component:	mod_ssl	Assignee:	Apache HTTPD Bugs Mailing List <bugs>
Status:	RESOLVED LATER
Severity:	enhancement	CC:	apache-bugzilla, apache_bugzilla, bdauvergne, duck, jean-francois.poirier, leanmeandonothingmachine, perske, putmanb, quintana.miguel, sascha-web-issues.apache.org, tonibony
Priority:	P2	Keywords:	MassUpdate, PatchAvailable
Version:	2.2-HEAD
Target Milestone:	---
Hardware:	All
OS:	All
Attachments:	Patch for trunk Patch for 2.2.x Patch for trunk Patch for 2.2.x Patch for trunk Patch for 2.2.x Patch for trunk

Description Scott Cantor 2008-09-30 11:06:18 UTC

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.

Comment 1 Paul Donohue 2010-04-13 15:39:22 UTC

*** Bug 46897 has been marked as a duplicate of this bug. ***

Comment 2 Paul Donohue 2010-04-14 11:25:28 UTC

I concur.  I have an application that does it's own independent validation and trust checking of the client's certificate, and there are cases where Apache's validation fails and disconnects the client even though I actually want it to ignore the error and let my application deal with it.  I still believe the optional_no_ca option is valuable (I think the intent there is to accept valid but untrusted certificates, which is different from accepting invalid certificates), so this should probably be implemented as a new option.

I'm attaching two patches (one that applies against 2.2.x and one that applies against trunk) to address this.  These patches add a new SSLVerifyClient option ('optional_no_verify') which will accept the certificate regardless of the validation result.  These patches include updated documentation which better describes the various SSLVerifyClient options and also corrects the ambiguities in the SSLProxyVerify documentation (which looks like it was copied and pasted from the SSLVerifyClient documentation).  These patches also correct the SSL_CLIENT_VERIFY variable so that it actually contains GENEROUS when verification fails but is accepted anyway (as per the existing documentation, see bug #45054), and so that it contains the verification error message if verification failed but was accepted anyway.

Comment 3 Paul Donohue 2010-04-14 11:27:56 UTC

Created attachment 25297 [details]
Patch for trunk

Comment 4 Paul Donohue 2010-04-14 11:28:30 UTC

Created attachment 25298 [details]
Patch for 2.2.x

Comment 5 Paul Donohue 2010-04-14 11:33:49 UTC

Note that if verification fails for multiple reasons and optional_no_ca or optional_no_verify is used, only the first verification error message is provided in the SSL_VERIFY_CLIENT message produced by this patch.  I wasn't sure how to fit this detail into the documentation, so I left it out.

Comment 6 Paul Donohue 2010-04-15 10:03:51 UTC

Created attachment 25303 [details]
Patch for trunk

Added an additional update to the documentation ... SSLProxyVerify and SSLProxyVerifyDepth are only valid in server/vhost config, not directory config.

They were originally defined in mod_ssl.c as valid only in the server/vhost config, but the documentation said they were also valid in directory config.  I don't think directory-level configuration makes much sense for these options, so I updated the documentation, but kept the existing definition in mod_ssl.c.

Comment 7 Paul Donohue 2010-04-15 10:04:36 UTC

Created attachment 25304 [details]
Patch for 2.2.x

Comment 8 Paul Donohue 2010-04-16 18:06:17 UTC

Created attachment 25313 [details]
Patch for trunk

Added some additional clarification to the documentation after consulting the TLS and SSLv2/v3 RFCs.

Comment 9 Paul Donohue 2010-04-16 18:08:31 UTC

Created attachment 25314 [details]
Patch for 2.2.x

Comment 10 Paul Donohue 2010-06-07 12:25:38 UTC

Created attachment 25539 [details]
Patch for trunk

Updated patch that applies cleanly to the current trunk.

Comment 11 Marc Stern 2011-11-10 12:58:42 UTC

We should also add the error code on top of the string message, this is much easier and safer to check in other places (other module, RewriteRule, etc.).

Comment 12 William A. Rowe Jr. 2018-11-07 21:08:18 UTC

Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.