> On 8 Sep 2016, at 2:26 AM, Marat Khalili <m...@rqc.ru> wrote: > >> It works beautifully and requires no restart of the server to >> add/remove/update certificates. > I am not an Apache developer, but it does not sound like a difficult patch. > Although I'd cache certificates in memory, not check filesystem every time. > It is not hard to type service apache2 reload when you need it. >
Oh yes, definitely cache the certificates. :) My sense is that many admins of large Apache installs prefer to minimize server restarts. It also simplifies the automation a bit not to need the restart. -FG > -- > > With Best Regards, > Marat Khalili > > On 08/09/16 06:04, Felipe Gasper wrote: >>> On 7 Sep 2016, at 9:43 PM, Marat Khalili <m...@rqc.ru> wrote: >>> >>> Did you consider having two instances of Apache: one for handling SSL with >>> vhost per certificate, and one for actual web sites with vhost per site? >>> First one will proxy requests to the second. Some people do it this way for >>> performance reasons, but it lets you be more flexible with certificates too. >>> >> I never considered this, but I would think the memory consumption of two >> Apache instances would be undesirable. Worth investigating, though. HAProxy >> may also work toward this end. >> >>>> All the same, would it not make sense to decouple the SNI logic from the >>>> vhosts? Just thinking at a conceptual level, there seems no particular >>>> reason why these entities are combined in the configuration. >>> Except for the fact that in 99.999% of use cases SNI determines vhost and >>> non-canonical domains are just redirects. >>> >> What do you mean by “non-canonical domain”? >> >> Do you mean something in the ServerAlias? That seems more an implementation >> detail of Apache’s particular configuration format; both conceptually and in >> practice all domains that point to a vhost are coequal in status, right? >> >>> OTOH, since every certificate contains domain names it is valid for, why >>> cannot Apache pick certificate from a list or directory automatically >>> before even considering virtualhosts? Isn't certificate-domain relationship >>> in Apache configuration redundant (in most cases) and error-prone? >> ^^^ Ding, ding, ding, ding, ding!!! :) >> >> This is how we’ve set up our own SNI-capable daemons: they load the cert >> chain and key from files named for the relevant domain. The service knows >> where the certs and key are as a function of the domain name; there’s no >> configuration besides filesystem setup. It works beautifully and requires no >> restart of the server to add/remove/update certificates. >> >> -FG >> >> >> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >>> >>> On September 8, 2016 3:03:35 AM GMT+03:00, Felipe Gasper >>> <fel...@felipegasper.com> wrote: >>> Reviving this thread … >>> >>> This would mean that every vhost will needs its own common.conf file, >>> which, on a server with thousands of vhosts, will make for expensive loads >>> of the configuration file. >>> >>> mod_macro in 2.4 is another route we may explore, but we have some really >>> complex vhost templating logic that would be difficult to port. >>> >>> All the same, would it not make sense to decouple the SNI logic from the >>> vhosts? Just thinking at a conceptual level, there seems no particular >>> reason why these entities are combined in the configuration. >>> >>> Are there plugin controls that would facilitate control of the SSL >>> certificate sent to the browser? Or would a change like this really need to >>> be in Apache itself? >>> >>> Thank you! >>> >>> -FG >>> >>> On 3 Feb 2016, at 5:54 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> >>> wrote: >>> common.conf: >>> <Locationwhatever... >>> ... >>> ... >>> --------------------------- >>> <VirtualHost *:443> >>> ServerName foo.tld >>> SSLCertificateFile foo.pem >>> Include common.con >>> </VirtualHost> >>> <VirtualHost *:443> >>> ServerName bar.tld >>> SSLCertificateFile bar.pem >>> Include common.con >>> </VirtualHost> >>> Am 03.02.2016 um 11:45 schrieb Felipe Gasper <fel...@felipegasper.com>: >>> What if I have a vhost with: >>> ServerName foo.tld >>> ServerAlias bar.tld >>> … but I have two separate SSL certificates for these domains? Is there >>> any way to accommodate this without either splitting the domains onto >>> separate vhosts or buying a new certificate that covers both domains? >>> -FG >>> On 3 Feb 2016 12:26 AM, William A Rowe Jr wrote: >>> Sounds like you have mis-structured the config. Per servername - each >>> can and should have its own cert and will be selected via SNI. If there >>> are subadmins beneath each vhost section #include those snippets and >>> they all still fall within the given host name. >>> On Feb 1, 2016 11:21 AM, "Felipe Gasper" <fel...@felipegasper.com >>> <mailto:fel...@felipegasper.com>> wrote: >>> On 1 Feb 2016 12:16 PM, Oscar Knorn wrote: >>> On 2016/02/01 Felipe Gasper wrote: >>> Hello, >>> Is it possible to do SNI SSL per domain rather than >>> per vhost? If >>> not, is there a feature request in for this? >>> Thank you! >>> -Felipe Gasper >>> Houston, TX >>> >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> <mailto:users-unsubscr...@httpd.apache.org> >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> <mailto:users-h...@httpd.apache.org> >>> Hello Felipe, >>> are'nt in your configuration the domains organized in vhost >>> sections >>> yet? Do you think, there might be a reason you can't organize >>> them that way? >>> Cheers Oscar >>> Hi Oscar, >>> Thanks for responding! >>> We have end users customizing their own vhost configurations via a >>> limited-access interface; hence, I can’t put one domain per vhost. >>> -F >>> >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> <mailto:users-unsubscr...@httpd.apache.org> >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> <mailto:users-h...@httpd.apache.org> >>> >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> >>> >>> >>> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >>> For additional commands, e-mail: users-h...@httpd.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org >> For additional commands, e-mail: users-h...@httpd.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
