httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kyle Hamilton" <>
Subject Re: Documentation for Apache httpd SSLVerifyClient considered harmful
Date Wed, 18 Apr 2012 20:20:12 GMT

I still think that a full rewrite is the best option for the entirety of the mod_ssl documentation,
and am looking forward to Symantec's contribution.

That said, if that falls through, I don't think that any specific product name should be mentioned
in the documentation unless it's clearly broken.  Safari's behavior can indeed be viewed as

If you want to use that directly, please strike the Safari parenthetical.

Otherwise, I have 4 suggestions (one for each parameter value) below.

On Wed, Apr 18, 2012 at 12:30 AM, Issac Goldstand <> wrote:
> I actually like Kyle's response here - maybe just add it verbatim?
> Kyle, if you could reword the "none" (trivial) and "require" in the same
> style, we can completely replace the whole sentence with a more detailed
> explanation.

SSLClientVerify none means that no verified TLS credentials shall be requested or received
from the client, and the application shall always be invoked.

SSLClientVerify require means that if a client does not provide an acceptable certificate
from a trusted CA in SSLCADNRequest{File|Path} (see their docs for their fallbacks), the application
shall not be invoked, instead relying on Apache httpd's ErrorDocument handlers when the client
authentication fails.  Most clients will not allow unacceptable certificate chains to be chosen
here, but if they do mod_ssl will verify they are correct and acceptable before invoking the

SSLClientVerify optional means that httpd shall request client certificate authentication.
 If the client does not prove an acceptable certificate from a trusted CA in SSLCADNRequest{File|Path},
the application will handle the 403 errorflow itself.  Most clients will not allow unacceptable
certificates to be chosen here, but if they do mod_ssl will verify they are correct and acceptable
before invoking the application.

(I'm actually not quite certain on the specific semantic here.  Will 'optional' still place
unacceptable certificates in the environment with SSLOptions +StdEnvVars and/or +ExportCertData?
 I don't think it should, but I've not read that code in a very long time.)

SSLClientVerify optional_no_ca means that httpd shall request client authentication, and the
application shall be invoked regardless of potential invalidity, unacceptability, or absence
of the certificate chain provided by the client.  With this configuration, the application
must handle its own access control.

Applications invoked by httpd receive the certificate data via the environment.  This is inhibited
by default for performance reasons.  SSLOptions +StdEnvVars and/or +ExportCertData must be
set for the application to obtain information about the client (and server) certificate chains.
 +ExportCertData is slightly less expensive than +StdEnvVars inside httpd, at the expense
of more time in the application to fully parse the client-provided chain.

> Being a user who's looked at client crypto, never really got it working,
> and would love to try again, I'd also be interested in a practical
> explanation of how to use "optional_no_ca" to handle the 403 response -
> best if it could be used in a CGI environment - and some more
> information (if there is any) on the Safari issue.  Reading your
> paragraph basically (as a user heeding the domain expert) tells me "If
> you want to support users on Safari, you're going to have to wrack your
> brain for some assbackward solution, or just otherwise give up"

This is the reason why I consider optional_no_ca to be the only legitimate answer. :)  I must
mention though, this behavior is not limited to Safari.  I first ran across it in Netscape
Navigator about 16 years ago, though I haven't checked recently if it's still the case in
Mozilla Firefox.  That behavior is, according to the TLS RFCs, the legitimate response when
a client cert is requested and the client doesn't have any certs from any acceptable CA.

The problem was that TLS/1.0 did not include a means to specify "I want to accept any CA",
and the effective response was "okay, we will only show CAs which have been whitelisted".
 With no client certs that chain to a whitelisted CA, the selection dialog shows all 0 of
the whitelisted certs.  (According to Nelson Bolyard with Mozilla a few years ago, this was
the motivation for the wildcard acceptable CA list in TLS/1.1.)

To handle things in CGI, this is where the environment variables come in.  With +ExportCertData,
use ${env:SSL_CLIENT_CERT} to get the same information as ${env:SSL_CLIENT_CERT_CHAIN_0} (PEM-encoded
client certificate).  Then if you need to verify its issuer, check ${env:SSL_CLIENT_CERT_CHAIN_1},
and so on.  If you're relying on critical subjectAltNames, this is the only way to obtain

If you don't need to worry about subjectAltNames, use +StdEnvVars, and obtain the distinguished
identity of the client with $SSL_CLIENT_I_DN.

> But I love where this is going.

This situation has a downside in that there is no standard way (except possibly JavaScript
CRMF handling) to request the creation of a keypair of any given type or parameters.  Microsoft
uses xenroll.dll as an ActiveX component to do so, Mozilla uses <keygen>, and <keygen>
is the most well-supported in other browsers.  keygen documentation will most likely not be
brought under the httpd umbrella, which unfortunately will mean that admins and developers
will still need to look elsewhere for the information they need to implement their apps.

Seriously, all that needs to be done is get rid of the "in practice" paragraph and I'll be
happy.  I'd rather get that done first before trying to perfect the rest of the prose, and
I'd rather evaluate Symantec's offer before working on that.

-Kyle H
View raw message