Re: SNI SSL per domain?

[Marat Khalili <mkh@xxxxxx>]

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.

> 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.

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?
-- 

With Best Regards,
Marat Khalili

On September 8, 2016 3:03:35 AM GMT+03:00, Felipe Gasper <felipe@xxxxxxxxxxxxxxxx> 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.eissing@xxxxxxxxxxxxx> 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 <felipe@xxxxxxxxxxxxxxxx>:
 
 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" <felipe@xxxxxxxxxxxxxxxx
 <mailto:felipe@xxxxxxxxxxxxxxxx>> 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-unsubscribe@xxxxxxxxxxxxxxxx
           <mailto:users-unsubscribe@xxxxxxxxxxxxxxxx>
           For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
           <mailto:users-help@xxxxxxxxxxxxxxxx>
 
 
 
       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-unsubscribe@xxxxxxxxxxxxxxxx
   <mailto:users-unsubscribe@xxxxxxxxxxxxxxxx>
   For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
   <mailto:users-help@xxxxxxxxxxxxxxxx>
 
 
 

 To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
 For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
 
 
 

 To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
 For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
 



To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx