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);
}
Rick Houser
Web Engineer
From: William A Rowe Jr <[email protected]>
Sent: Monday, September 17, 2018 16:27
To: httpd <[email protected]>
Subject: Re: minor nit in mod_ssl
EXTERNAL EMAIL
On Mon, Sep 17, 2018 at 2:56 AM Stefan Eissing
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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<http://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): [client 127.0.0.1:34974<http://127.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): [client 127.0.0.1:35330<http://127.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.
