Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Felipe Gasper <felipe@felipegasper.com>
In-Reply-To: <18f813ad-9ce1-ded0-3480-569cb668417d@rqc.ru>
Date: Thu, 8 Sep 2016 02:38:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <2C17222F-63DF-4A13-ACE2-75F4630D87B8@felipegasper.com>
References: <56AF895F.5060704@felipegasper.com> <56AF92E0.1020104@uni-due.de> <56AF93ED.5020005@felipegasper.com> <CACsi251QTqg7fh=vvBP-02dkJrgdNkQPm_u_yM7u13aee0BY7w@mail.gmail.com> <56B1DA3D.8060102@felipegasper.com> <BF0B37EA-82C5-4C8E-98E1-6981B8F8695E@greenbytes.de> <043FCDE2-3C6F-4781-8C0F-A9F01F8EA4E4@felipegasper.com> <61D2B92F-143D-4761-B3AD-D084705CA6CD@rqc.ru> <A8529A84-8A48-456B-A518-BC483AFDE0B5@felipegasper.com> <18f813ad-9ce1-ded0-3480-569cb668417d@rqc.ru>
To: users@httpd.apache.org
Subject: Re: [users@httpd] SNI SSL per domain?
archived-at: Thu, 08 Sep 2016 07:38:30 -0000


> On 8 Sep 2016, at 2:26 AM, Marat Khalili <mkh@rqc.ru> wrote:
>=20
>> 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.
>=20

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

> --
>=20
> With Best Regards,
> Marat Khalili
>=20
> On 08/09/16 06:04, Felipe Gasper wrote:
>>> On 7 Sep 2016, at 9:43 PM, Marat Khalili <mkh@rqc.ru> wrote:
>>>=20
>>> 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.
>>>=20
>> 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.
>>=20
>>>> 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.
>>>=20
>> What do you mean by =E2=80=9Cnon-canonical domain=E2=80=9D?
>>=20
>> Do you mean something in the ServerAlias? That seems more an =
implementation detail of Apache=E2=80=99s particular configuration =
format; both conceptually and in practice all domains that point to a =
vhost are coequal in status, right?
>>=20
>>> 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!!! :)
>>=20
>> This is how we=E2=80=99ve 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=E2=80=99s no configuration besides filesystem setup. =
It works beautifully and requires no restart of the server to =
add/remove/update certificates.
>>=20
>> -FG
>>=20
>>=20
>>=20
>>> --=20
>>>=20
>>> With Best Regards,
>>> Marat Khalili
>>>=20
>>> On September 8, 2016 3:03:35 AM GMT+03:00, Felipe Gasper =
<felipe@felipegasper.com> wrote:
>>> Reviving this thread =E2=80=A6
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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.
>>>=20
>>> 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?
>>>=20
>>> Thank you!
>>>=20
>>> -FG
>>>=20
>>>  On 3 Feb 2016, at 5:54 AM, Stefan Eissing =
<stefan.eissing@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 =
<felipe@felipegasper.com>:
>>>    What if I have a vhost with:
>>>    ServerName foo.tld
>>>  ServerAlias bar.tld
>>>    =E2=80=A6 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@felipegasper.com
>>>  <mailto:felipe@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
>>> =20
>>>            To unsubscribe, e-mail: =
users-unsubscribe@httpd.apache.org
>>>            <mailto:users-unsubscribe@httpd.apache.org>
>>>            For additional commands, e-mail: =
users-help@httpd.apache.org
>>>            <mailto:users-help@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=E2=80=99t put one domain =
per vhost.
>>>      -F
>>> =20
>>>    To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>    <mailto:users-unsubscribe@httpd.apache.org>
>>>    For additional commands, e-mail: users-help@httpd.apache.org
>>>    <mailto:users-help@httpd.apache.org>
>>>     =20
>>>  To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>  For additional commands, e-mail: users-help@httpd.apache.org
>>>     =20
>>>  To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>>  For additional commands, e-mail: users-help@httpd.apache.org
>>> =20
>>>=20
>>>=20
>>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>>> For additional commands, e-mail: users-help@httpd.apache.org
>>>=20
>>=20
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
>> For additional commands, e-mail: users-help@httpd.apache.org
>>=20
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>=20


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org