----- Original Message ----- From: "Vivek Khera" <[EMAIL PROTECTED]> Newsgroups: ml.apache.modperl To: <[EMAIL PROTECTED]> Sent: Wednesday, November 06, 2002 6:52 PM Subject: Re: sending ssl certificate according to virtual host
> >>>>> "MJ" == Mathieu Jondet <[EMAIL PROTECTED]> writes: > > MJ> Depending on the vh requested I set the SSLCertificateFile and > MJ> SSLCertificateKeyFile which will point to the correct ssl files for the > MJ> requested vh. > > What they should have done is what is done now with TLS in SMTP. You > connect to the same port, but issue a "STARTTLS" command to switch > over to secured mode. With this type of scheme, the header info with > the desired host could be in the initial request, so then you could > pick the right certificates to use. Alas, the HTTP protocol doesn't > work this way as far as I can tell. > I dunno... What if you want to send a cookie in secured mode? That's part of the headers, and of equal "priority" as the Hostname: header used to determine the correct VirtualHost to use... I'm sure that SSL could be fit much nicer over HTTP/1.1, but it would probably rip apart alot of the solid standards involved - such as creating priorities inside the headers, or the option to take multiple commands... Origianlly, when writing this email, I was going to suggest a CONNECT / STARTTLS scheme which would work in Keep-Alive mode until the server clsoed the connection... But then I found an existing RFC which describes it - so the question (probably a stupid one which I don't realize is stupid only because I just now stumbled accross the RFC and still don'ty properly understand what's involved) is: why is it not implemented? Anyway, the RFC in question is 2817 (http://www.ietf.org/rfc//rfc2817.txt) Issac