Issac, 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 working-as-designed. 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 <mar...@beamartyr.net> 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 application.
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 them.
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
Verify This Message with Penango.p7s
Description: S/MIME Cryptographic Signature
