> -----Original Message----- > From: Chirouze Olivier [mailto:olivier.chirouze@xxxxxxxxx] > Sent: Thursday, March 22, 2007 2:39 PM > To: users@xxxxxxxxxxxxxxxx > Subject: RE: Request for Input: ApacheCon SSL Training > > Hi Issac, thanks for the info. > I'll read the RFC carefully. > Regarding mod_ssl, a quick look at the FAQ doesn't seem to prove it's > supported: http://www.modssl.org/docs/2.8/ssl_faq.html#vhosts > http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts > > Could you give more information about potential mod_ssl > supporting name > based vhosts? I suppose the FAQ could be out of date... The FAQ is fine - it describes the situation as it is on the vast majority of extant browsers and servers. The RFC you are going to read carefully describes a new proposal; basically, to put an additional header into the cleartext preamble before the SSL session is established. This additional header will contain the hostname and so, when the server comes to do the SSL negotiation, it will already know the hostname and so will know what VH to go to and so will be able to get the correct certificate. NBVHing will then work over SSL! I'm not sure about the uptake of this new standard - obviously it relies on the browser sending the new header in the request and I don't know what, if any, plans there are for building it into new browsers. The trouble might be that it's an improvement that helps the server (it can use NBVH) but the work (generating the extra header) has to be done in the client-community. The client doesn't noticeably gain anything since the TCP/IP details of the server are hidden behind the domain-name (ie, the user just types a domain-name into the browser and dowsn't know or care whether the host is IP-based or name-based). Rgds, Owen Boyle Disclaimer: Any disclaimer attached to this message may be ignored. > > Thanks, > > Olivier > > Olivier CHIROUZE > I&0 Infrastructure > Volvo Information Technology > > > > -----Original Message----- > > From: Issac Goldstand [mailto:margol@xxxxxxxxxxxxx] > > Sent: 19 March 2007 11:15 > > To: users@xxxxxxxxxxxxxxxx > > Subject: Re: Request for Input: ApacheCon SSL Training > > > > Wildcard support shouldn't have to be official, because there *is* > > name-based virtualhost support for SSL. It's well documented in RFC > > 2817 and 2818 and according to the cipher list, is supported by most > > recent versions of mod_ssl in Apache 2.x > > > > If you want to push "how to better allow for name-based SSL", it > > shouldn't be to find more workarounds - it should be about > how to get > > the existing standards into more servers and browsers and > > make their use > > a standard practice. > > > > Just my $0.02, > > Issac > > > > > > Chirouze Olivier wrote: > > > Hi, > > > > > > I'm sorry I always insist on wildcard certificates being > > not officialy > > > supported by Apache, but I think that's something to know > > about. You can > > > save a bunch of dollars a year with this trick ;-) > > > > > > Here's what I recently wrote for a doc, feel free to > > correct me if I'm > > > wrong: > > > > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------------------ > > > Name based virtual hosting is not officially compatible > with HTTPS. > > > > > > The reason is: > > > 1) the request received by Apache is encrypted: > only the source and > > > destination IP addresses can be read by Apache (it is in > > the TCP header, > > > not the encrypted HTTP request) > > > 2) for this reason, when using name based virtual > host, no virtual > > > host can be associated with the HTTPS request > > > 3) by default, the first SSLCertificateFile > directive found is > > > used: the first SSL certificate found is used > > > > > > However, if a single "wildcard" certificate is used by all > > virtual hosts > > > on the same IP, then: > > > 4) the first certificate found is correct > > > 5) the request can be decrypted > > > 6) the server name can now be read and the right > virtual host is > > > found > > > 7) the rest of the process is similar to normal HTTP > > > > > > A few consequences: > > > - it only works because all the virtual hosts on the same IP use > > > the same SSL certificate > > > - because they are virtual hosts with different names (hence the > > > "name based"), the certificate can only be a "wildcard" > > certificate... > > > - when using this "unsupported feature" it is very important to > > > make it clear that the virtual hosts use the same > certificate => for > > > example, move the "SSLCertificateFile" directive in a file > > and include > > > it in all your virtual hosts. Then a change in this file > > will clearly > > > affect all your virtual hosts. > > > > > > Very logically, wildcard certificates aren't officially > supported by > > > Apache either. > > > > > > Apache, when starting up, compares the server name of the SSL > > > certificate with the configuration (virtual host) server name. > > > Thus, when using a wildcard certificate, you will get such > > a warning at > > > startup: > > > > > > [Fri Jul 21 13:40:10 2006] [warn] RSA server certificate > > CommonName (CN) > > > `*.myserver.com' does NOT match server name!? > > > > > > See: > > > - > > > > > http://mail-archives.apache.org/mod_mbox/httpd-bugs/200512.mbo > > x/%3C20051 > > > 214183548.6B3CC184@xxxxxxxxxxxxxxx%3E > > > - http://www.lists.aldigital.co.uk/apache-ssl/msg03957.html > > > > > > Reference: > http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts > > > > > > > > -------------------------------------------------------------- > > ---------- > > > ------------------------------------ > > > > > > I'd be proud if I can help for ApacheCon ;-) > > > > > > Olivier > > > > > > Olivier CHIROUZE > > > I&0 Infrastructure > > > Volvo Information Technology > > > > > > > > > > > >> -----Original Message----- > > >> From: Vincent Bray [mailto:noodlet@xxxxxxxxx] > > >> Sent: 19 March 2007 10:09 > > >> To: users@xxxxxxxxxxxxxxxx > > >> Subject: Re: Request for Input: ApacheCon > > SSL Training > > >> > > >> On 19/03/07, Sander Temme <sctemme@xxxxxxxxxx> wrote: > > >> > > >>> Dear list, > > >>> > > >>> As I prepare my training session title "Practical SSL > > Implementation > > >>> with Apache" for the upcoming ApacheCon EU conference, I > > would like > > >>> to take a moment and request your feedback. > > >>> > > >> #apache on freenode commonly sees quesions from people > > confused by the > > >> various certificate formats and by the openssl command (hardly > > >> surprising considering its man page). Perhaps some > coverage of the > > >> difference between pem/der/crt/whatever, and maybe ways to > > >> validate/convert those formats? > > >> > > >> I can't attend the conference but I hope it turns out well, > > >> good luck :) > > >> > > >> -- > > >> noodl > > >> > > >> > > > --------------------------------------------------------------------- > > >> The official User-To-User support forum of the Apache HTTP > > >> Server Project. > > >> See <URL:http://httpd.apache.org/userslist.html> for more info. > > >> To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > > >> " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > > >> For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > > The official User-To-User support forum of the Apache HTTP > > Server Project. > > > See <URL:http://httpd.apache.org/userslist.html> for more info. > > > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > > > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > > > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > > > > > > > > > > > > --------------------------------------------------------------------- > > The official User-To-User support forum of the Apache HTTP > > Server Project. > > See <URL:http://httpd.apache.org/userslist.html> for more info. > > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > > > > --------------------------------------------------------------------- > The official User-To-User support forum of the Apache HTTP > Server Project. > See <URL:http://httpd.apache.org/userslist.html> for more info. > To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx > " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx > For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx > This message is for the named person's use only. It may contain confidential, proprietary or legally privileged information. No confidentiality or privilege is waived or lost by any mistransmission. If you receive this message in error, please notify the sender urgently and then immediately delete the message and any copies of it from your system. Please also immediately destroy any hardcopies of the message. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. The sender's company reserves the right to monitor all e-mail communications through their networks. Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of the sender's company. --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|