yup ok, thanks, I see why it is too late now... obvious...
"Nelson B. Bolyard" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> Luke Amery wrote:
>
> > just a quick SSL/TLS question, I don't know if this is the right general
> > area, but here goes.
> >
> > Reading the TLS rfc and netscape ssl draft it appears to me that the
server
> > can initiate a renegotiation request at anytime.
>
> At any time that no SSL/TLS handshake is already in progress. But as soon
> as one handshake finishes, the server can request that another begin.
>
> Servers often do this to request that the client perform authentication
> as part of access control for the requested URL.
>
> > If this is the case, would it be possible to actually receive the
headers of
> > a http client request using one server certificate and then ask the
client
> > to renegotiate, and receive the remaining portion of the request (if
any)
> > and then send the response using another server certificate?
>
> Yes, that's conceivable. Servers often do one handshake, receive the http
> request, look up the requested "page", see that it requires
authentication,
> and then initiate another SSL handshake requesting client authentication.
> But they typically do not change server certs in the process.
>
> One reason they might change certificates is to present a certificate with
a
> different type of public key in it, e.g. switching from an RSA public key
to
> a DSA public key, or vice versa, because the client attempted to negotiate
a
> different set of ciphersuites in the second handshake.
>
> > The reason I ask is obviously to determine if it is possible to host
> > multiple ssl certificates off a single IP address, using host headers to
> > determine which ultimate certificate to use to do the bulk of the http
> > transaction.
>
> It's too late at that point. The SSL client logic in the browser (or
> other SSL client) has to ensure that the cert matches the intended server
> before it allows any of the application protocol (e.g. the https request)
> to be transferred.
>
> Very recently, a new RFC has come out proposing an extension to the TLS
> negotiation that allows the client to tell the server in advance which of
> the server's multiple identities it should take on in the subsequent
> handshake. However, I do not know of any server products or browsers that
> implement that feature yet.
>
> --
> Nelson Bolyard
> Disclaimer: I speak for myself, not for Netscape
