[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [neon] Re: Fun with certificate authentication

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2002-08-06 00:50:42 CEST

On Mon, 5 Aug 2002, Joe Orton wrote:

> On Mon, Aug 05, 2002 at 09:01:46AM -0400, Daniel Berlin wrote:
> > On Mon, 5 Aug 2002, Daniel Stenberg wrote:
> >
> > > On Mon, 5 Aug 2002, Daniel Berlin wrote:
> > >
> > > > The first thing that occurred when i woke up this morning was that the PEM
> > > > reader can't use the default private key prompt because it doesn't take a
> > > > context argument.
> > >
> > > Is that really so?
> >
> > Yup.
> > they take:
> > (FILE *, <X509 ** or EVP_PKEY ** in the cases we call them for>, password
> > callback, userdata).
> >
> > None of them take a CTX.
> >
> > I would imagine this is becuse they are in libcrypto, and not libssl.
> > They don't want to require an SSL ctx just to read certificates.
> >
> > However, maybe instead, neon should use the SSL_CTX_* functions that read
> > certificates into the SSL context, and probably use the default password
> > callback since they take a context.
>
> I looked into this - since the SSL_CTX_* functions load the cert and key
> directly into the SSL_CTX structure, the callback-based client cert
> provider function would need to somehow extract the EVP_KEY * and X509 *
> back out of the SSL_CTX after ne_ssl_load_* was called. I couldn't find
> an obvious way of doing that with the OpenSSL API.
There's little point anyway, i just bothered
to look at the implementation, and SSL_CTX_use_certificate_file
is almost identical to what we are doing, it just passes the callbacks.

--Dan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 6 00:51:12 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.