The SSL library uses struct cert_st (aka CERT; defined in ssl_locl.h)
in different ways, and the whole thing is rather confusing:
First, there's the "default_cert" component in SSL_CTX's, which holds
private keys and certificates and also temporary keys and callbacks;
then, there's the same in SSL's. There are some inconsistencies
about the use of callbacks and explicitly set temporary keys between
SSL_CTX's on the one hand and SSL's on the other hand -- we were
already discussing that some time ago. It should not be too hard to
fix these inconsistencies -- in my opinion the SSL_CTX_... API should
be quite closely mirrored by the SSL_... API, and SSL_new would copy
everything from the underlying SSL_CTX so that you could change just
those settings that you want to be different.
Finally, we also have a struct cert_st in SSL_SESSIONs, and that's
were things become really strange: s3_clnt.c apparently uses this
structure to store the *server's* certificate (while in SSL_CTX and
SSL the structure is used to store the own key and certificate), which
is also duplicated in the SSL_SESSION's "peer" component. s3_srv.c
behave quite different and points s->session->cert to the cert_st
give by the SSL's "cert" pointer (or, if that pointer is NULL -- which
I don't think can really happen --, it uses the SSL_CTX's
"default_cert"; but s->cert is initially the same as
s->ctx->default_cert anyway). If the SSL's settings differ from the
SSL_CTX's settings, then s->cert is a structure that is used only
for the current connection; however, if the SSL_CTX's "default_cert"
is used, then s->cert and hence s->session->cert can be shared among
various connections -- but s3_srvr.c uses s->session->cert->cert_chain
to store the verification chain, minus the actual client certificate.
Now this is obviously wrong.
It appears to me that while it is reasonable to employ the same
cert_st structure for SSL_CTX's and SSL's (if the inconsistencies in
the current code are removed, as I suggested in the first paragraph),
the re-use of cert_st for sessions makes not a lot of sense
altogether; that is, not only is the current implementation broken,
but a corrected one should use a specific data structure that
is appropriate for its needs instead of kludging around with cert_st.
But if someone has a certain view what the "canonical" way to handle
these things is, let me known.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
