httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [users@httpd] RE: Apache SSL Feature - Please Advise (PATCH for mod_ssl)
Date Fri, 10 Dec 2004 18:24:29 GMT
  I have attached three patch versions. Writing the code is not nearly as difficult as figuring
out the best way to go.

Patch 1 (proof of concept)
source: ssl_engine_init.c, ssl_engine_kernel.c
I really don't expect this one to go simply because I merely changed the meaning of the existing
directives to what I had initially assumed when I bumped into the limitation. I simply force
SSLCACertificateFile to be used for the cert store load for client authentication only and
force SSLCACertificatePath to be used for the client_CA STACK_OF(X509_NAME) only. This patch
requires both directives be configured if client verify is enabled. Obviously, this one is
not downward compatible with existing configurations.

Patch 2 (special use case)
source: ssl_engine_init.c, ssl_engine_kernel.c
Again, no new directives but if only one of the SSLCACertificate* directives are specified,
mod_ssl will behave as it did before (load certs into the cert store and load names into the
client_CA stack list). However, if both are specified it behaves like patch 1. This will I
think preserve downward compatibility with most configs. I like this one because intuitively
it is what I would expect. Wasn't the hashing of CA names for symbolic links intended to expedite
the creation of the opaque DistinguishedName list of the handshake CertificateRequest message
(RFC2246)? However, I realize it is not 100% downward compatible.

Patch 3 (new config)
source: ssl_engine_init.c, ssl_engine_kernel.c, ssl_engine_config.c, mod_ssl.c, mod_ssl.h
Two new directives, SSLCADNRequestFile and SSLCADNRequestPath. I figured I might as well give
the same flexibility. If the new directives are not specified old behavior continues. If either
or both SSLCADNRequest* is configured, they would configure the client_CA stack ONLY and any
SSLCACertificate* directive(s) will be used for the cert store load ONLY. The benefit here
is complete downward compatibility. No requirement to use the new directives and no change
in meaning for the use of existing directives (except when new is used too).

I look for your recommendation, Ben, and solicit comments of those interested. Please note
this capability is important to us in the U.S. Department of Defense. It saves CRL bandwidth
and processing, as well as, eliminates user questions and confusion for thousands.


-----Original Message-----
From: Ben Laurie []
Sent: Sunday, November 21, 2004 10:01 AM
Subject: Re: Apache SSL Feature - Please Advise

> Hello Ben.
> I have a situation where I believe Apache is limiting an SSL
> capability that I need to be able to use. I posted the following on
> the apache user mail list but got no response. I want to know if I
> should look into making the change myself and present it as a patch,
> just open a bug report or is there some other means for requesting a
> new feature that won't evoke derisive laughter.
> My post to [users@httpd]: First of all, I have already asked on the
> OpenSSL and was referred to Apache, so here goes.
> Premise 1 SSL/TLS Handshake has a certificateRequest message (for
> client authentication) that will prompt the browser for a
> certificate. Now the Draft (SSL)/RFC (TLS) state that in the
> certificateRequest the server may include a list of acceptable CA's.
> Premise 2 After receiving a certificate from the client in response
> to a certificate request SSL/TLS will perform validation (not out of
> date, not a forgery, and, if configured, not revoked). During
> validation a trust list of CAs is consulted to validate the
> certificate chain.
> My Problem My organization has a Root CA which has subordinate
> (intermediate) CAs of two different classes. I only want to accept
> certificates from one of the subordinate CA classes. Mind you that
> both classes issue RSA-signing certificates. This causes my end
> users, who have a certificate from each of the two subordinate CA
> classes, to get prompted to pick a certificate to authenticate with.
> I have good reasons for needing to eliminate the selection prompt
> (user confusion, CRL bandwidth use, etc). Using functionality of
> premise 1, I can specify only (let's say) Class A  CAs in the
> certificateRequest message. If don't include the root CA in that
> list, I see the browser response I want, only Class A Certificates
> are eligible (and presented to user) for use. However, It won't
> validate because of the lack of a root CA. If I include the Root CA
> in the premise 1 list with the Class A CA's, the user is presented
> with both Class A and Class B certificates, obviously because both
> are valid for that Root CA trust anchor. :-(  That's right, darned if
> I do and darned if I don't.
> Apache SSL Configuration Limitation SSLCACertificateFile and
> SSLCACertificatePath are documented as interchangeable. I have found
> no configuration of directives that will give me separate control of
> the certificateRequest (premise 1) and the validation trust list
> (premise 2). They are treated as one and the same and I recognize
> that for most that is fine.
> Openssl Functionality Openssl development has stated that openssl
> does not force them to be the same.
> Therefore, I am led to believe that apache is using the same list for
> both (premise) purposes. Is this an opportunity for a new Apache SSL
> directive? I am thinking of a new directive for trust anchors only.
> The code could be changed to look for the setting for this directive
> at path validation time, and if not null, load any CAs defined there
> (file/path) into the context cert store.This would be a fairly simple
> change and would keep backward compatibility with existing SSL
> configurations.
> How would you recommend I proceed?

Apologies for the delay, I've been travelling.

If you can write the code, then by all means send me a patch.




"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message