> Am 18.09.2018 um 15:44 schrieb Houser, Rick <rick.hou...@jackson.com>:
> 
> 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?
>  
> --- httpd-2.4.10_backup/modules/ssl/ssl_engine_init.c   2015-09-30 
> 07:50:30.000000000 -0400
> +++  httpd-2.4.10/modules/ssl/ssl_engine_init.c_new     2015-10-19 
> 16:13:51.716000988 -0400
> @@ -1002,7 +1002,7 @@
>  
>      if (modssl_X509_match_name(ptemp, cert, (const char *)s->server_hostname,
>                                 TRUE, s) == FALSE) {
> -        ap_log_error(APLOG_MARK, APLOG_WARNING, 0, s, APLOGNO(01909)
> +        ap_log_error(APLOG_MARK, APLOG_DEBUG, 0, s, APLOGNO(01909)
>                       "%s server certificate does NOT include an ID "
>                       "which matches the server name", key_id);
>      }
>  

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?

-Stefan

>  
> Rick Houser
> Web Engineer
>  
> From: William A Rowe Jr <wr...@rowe-clan.net> 
> Sent: Monday, September 17, 2018 16:27
> To: httpd <dev@httpd.apache.org>
> Subject: Re: minor nit in mod_ssl
>  
> EXTERNAL EMAIL
> 
> 
> On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing <stefan.eiss...@greenbytes.de> 
> wrote:
> >
> > mod_ssl/ssl_engine.kernel.c, 353: logs ERR (APLOGNO(02033)) when 
> > strict_sni_vhost_check is enabled and a request comes in without SNI. 
> >
> > Question: is a downgrade from ERR to INFO/DEBUG backportable or do we 
> > consider this a break of compatibility?
> 
> 
>  
> On Mon, Sep 17, 2018 at 10:43 AM William A Rowe Jr <wr...@rowe-clan.net> 
> wrote:
> >
> > It is entirely appropriate to turn down the volume. That's what 
> > module-by-module loglevels are there for.
> 
> 
> This is the loglevel of typical garbage request streams;
> 
> [Mon Sep 17 11:44:43.036820 2018] [core:debug] [pid 26317:tid 
> 140199172134656] protocol.c(965): (20014)Internal error (specific information 
> not available): [client 127.0.0.1:34974] Failed to read request header line 
> (null)
> [Mon Sep 17 11:44:43.036871 2018] [core:debug] [pid 26317:tid 
> 140199172134656] protocol.c(1318): [client127.0.0.1:34974] AH00567: request 
> failed: error reading the headers
> [Mon Sep 17 15:24:46.146311 2018] [core:debug] [pid 26413:tid 
> 140199180527360] protocol.c(860): [client127.0.0.1:35330] AH02418: HTTP 
> Request Line; Unrecognized protocol 'HTTP/1.xx' (perhaps whitespace was 
> injected?)
> 
> It seems that TLS missing SNI fits this same debug-level pattern of 
> diagnostics.

Reply via email to