osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: minor nit in mod_ssl


Vhosts have all the usual stuff with Document root, logging, etc.  TLS is configured globally (serverhost.serverdomain.tld) , but if we were receiving connections on multiple IP addresses, I could see setting that up within each vhost to a value that does not match ServerName as well.

Listen 8012
<VirtualHost *:8012>
    ServerName address1.example.com
</VirtualHost>

Listen 8013
<VirtualHost *:8013>
    ServerName address2.example.com
</VirtualHost>


I'd be happy to clarify if any specifics aren't clear, but I think this is a general problem related to scope clash with attributes from different parts of communication stack, not something related to the specific configuration.  Please see my response to William about 20 mintues back for more clarification on that.


Rick Houser
Web Engineer

> -----Original Message-----
> From: Stefan Eissing <stefan.eissing@xxxxxxxxxxxxx>
> Sent: Thursday, September 20, 2018 05:03
> To: dev@xxxxxxxxxxxxxxxx
> Subject: Re: minor nit in mod_ssl
> 
> EXTERNAL EMAIL
> 
> 
> 
> > Am 19.09.2018 um 17:17 schrieb William A Rowe Jr <wrowe@rowe-
> clan.net>:
> >
> > On Wed, Sep 19, 2018 at 6:39 AM Stefan Eissing
> <stefan.eissing@xxxxxxxxxxxxx> wrote:
> >
> > > Am 18.09.2018 um 15:44 schrieb Houser, Rick
> <rick.houser@xxxxxxxxxxx>:
> > >
> > > In the same vein, I’ve been running this patch on our builds to get around
> a warning for certificates not matching the hostname.  Certificates are not
> expected to match the hostname with many load balancing/uptime
> detection schemes, and this one logs a LOT when it trips on every vhost.
> Perhaps this patch should share the same fate as decided for the TLS missing
> SNI issue?
> >
> > Not sure I understand your setup here. Is this the ServerName from the
> global server? Otherwise, in a VirtualHost why would you not set the
> ServerName to the hostname you are serving?
> >
> > Envision a TCP load balancer routing TLS-crypted traffic across a number
> > of internal hosts, with each of the named virtual hosts presenting the
> correct
> > certificate, and known to httpd by their ServerAlias on the outer-facing
> interface.
> > Not terminated at the edge balancer.
> >
> > There is the issue of keeping TLS session key encoding in sync across
> > the backends, obviously.
> 
> Yes, I can see that. But the mentioned APLOG_WARN only triggers for s-
> >server_hostname, not the Alias list.
> 
> I therefore imagine the setup to be like:
> 
> tcp-balancer (x.domain.org)
>   - host a.internal.net
>       <VirtualHost *:443>
>         ServerName a.internal.net
>         ServerAlias x.domain.org
>         SSLCertificateFile cert-for-x.domain.org.pem
>       </VirtualHost>
> 
>   - host b.internal.net
>       <VirtualHost *:443>
>         ServerName b.internal.net
>         ServerAlias x.domain.org
>         SSLCertificateFile cert-for-x.domain.org.pem
>       </VirtualHost>
> 
> and maybe that is nicer than writing
>       <VirtualHost *:443>
>         ServerName x.domain.org
>         ServerAlias b.internal.net
>         SSLCertificateFile cert-for-x.domain.org.pem
>       </VirtualHost>
> 
> or it has side-effects that I do not understand. Or, the config is like:
>       SSLCertificateFile cert-for-x.domain.org.pem
>       <VirtualHost *:443>
>         ServerName b.internal.net
>       </VirtualHost>
>       <VirtualHost *:443>
>         ServerName x.domain.org
>       </VirtualHost>
> 
> Any way, I would like to understand the issue before removing the
> APLOG_WARN about non-matching certificates. Which is a valid warning
> and can prevent debug frustration.
> 
> Rick, can you help me out here?
> 
> -Stefan