Ralf S. Engelschall wrote:
>
> On Thu, Jun 24, 1999, Matthias Loepfe wrote:
>
> > [...]
> > > Hmmm... the client handling should be done on-the-fly. But perhaps the
> > > loading is already broken. You can find it in functions
> > > SSL_CA_load_certs_file() and SSL_CA_load_certs_path() in ssl_util_ssl.c. The
> > > on-the-fly handling is done by ssl_ext_mp_clientcert_cb() in ssl_engine_ext.c.
> > > You can debug this by adding some ssl_log() calls to this function.
> > > Perhaps no CA matches the client certs.
> >
> > I already stept through the code with the debugger before I sent the last
> > mail. To me it looks as if the whole code for the loading of the private keys
> > is missing.
> >
> > I think the name of the function which loads the certs
> > 'SSL_CA_load_certs_file()' is strange (probably legacy). The 'CA' means for me
> > it was written to load CA certs for which we never have to load a private key.
> > The other thing is that if you load a file with multiple certs in it how can
> > you easily assign and find the private keys. I expect for this usage that
> > each file MUST contain the cert and the private key and only that.
>
> Hmmm... SSL_CA_load_certs_file() calls PEM_X509_INFO_read_bio() and this is
> aware of both X509 certs and private keys. One actually gets back a stack of
> info structures which contain both certs and keys. So the code it correct, but
> the function names are bugus, of course. But you're right. This silently
> assumes that first the certs and keys are bundled together into the same file
> and second that the keys are all unencrypted.
>
> > As the private keys are normaly encrypted I think we should add these certs and
> > keys to the 'szPublicCertFile' and 'szPrivateKeyFile' arrays so that they get
> > handled by the 'ssl_pphrase_Handle' function.
> >
> > What do you think?
>
> Hmmm... yes, I think Strongholds old assumptions are too unrealistic. We
> should allow these client keys to be encrypted. And you're right, for these
> we've to pre-process the proxy stuff already at startup so they are handled by
> the pass phrase dialog.
>
> I think let us do the things step by step. First try to put certs and
> unecnrypted keys into own files to let the proxy stuff work the first time.
With this assumptions the proxy stuff seams to work properly!
> Then we can add the support for encrypted keys be pre-processing the proxy
> configuration at startup.
Thats what I wanna do now. I had a look at your code doing cert and key handling
and have the following succestion and questions:
1. in the function 'ssl_ext_mp_init' the code for the loading of the certs must
changed in the following way:
- the real loading must be done in the 'ssl_pphrase_Handle' function so that
foreach virtual host the original code will be called. Then for each
encrypted key there must be something simmilar like the loop over
sc->szPublicCertFile[i]. Then the X509_INFO stack must be converted to
a stack of asn1 versions of the certs and keys.
- the function 'ssl_ext_mp_init' must then (only in phase 2) convert the
'asn1' stack back to a X509_INFO stack
2. Some time ago I started implementing a more performant version of a ssl
reverse proxy. I thought that a new construct like
<ProxyDest theDest1>
...
</ProxyDest>
With that the proxy configuration is no longer tied 1:1 to the virtual host.
It is possible to make different configurations for different logical
destinations. There could be more than one destination server for
fault tollerance and load balancing. The 'ProxyPass' or rewrite rule would
simply name the logical proxy instead of the DNS name which gets resolved
for each request. e.g. 'ProxyPass' /dest1 https://<theDest1>/theContent1
Unfortunately the support for such new configuration is not very good.
eventhough I had a working implementation (attached). What do you think
would it be worth to merge this with you code?
What we would get is a stack or something simmilar with proxy destination
configurations attached to the module.
>
> Thank you again for helping me out making this stuff working. It's very
> interesting stuff which should go into mod_ssl 2.4 in a useable fashion. Sorry
> that I've not time to work on this currently. That's why I'm very happy that
> you help out.
>
> Greetings,
> Ralf S. Engelschall
> [EMAIL PROTECTED]
> www.engelschall.com
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
regards
Matthias
-------------------------------------------------------------------------------
Matthias Loepfe, AdNovum Informatik AG, Roentgenstr. 22, CH-8005 Zurich
Email: [EMAIL PROTECTED] Voice: +41 1 272 6111 Fax: +41 1 272 6312
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
