[Sat Nov 04 13:36:50 2017] [error] Hostname www.jwz.org provided via SNI and hostname www.dnalounge.com provided via HTTP are different
Conveniently, Apache doesn't log the IP address of the offending connection, only the time, so it's not always easy to guess which client is the problem. That one appears to be from Feedly, attempting to fetch the DNA Lounge blog, while using www.dnalounge.com in the Host header but using www.jwz.org in the SSL layer.
I can't even fathom how they might have fucked up that way.
So I tried adding "SSLStrictSNIVHostCheck on" to httpd.conf and that just made it worse: now I get these with even more frequency than I was getting the other warnings:
[Sat Nov 04 13:42:40 2017] [error] No hostname was provided via SNI for a name based virtual host
I'm guessing most of those are from RSS readers too, but it's hard to tell.
I just want to turn all of these warnings off. Is there a way?
Update: The majority of these errors were coming from Feedly; they have since fixed their bug, which quieted it down a lot. I am still getting them from other places, though.
I can answer your middle question, how they likely fucked up -- they are reusing existing connections based on IP address. You can't do that with TLS; they need to key on hostname. I found and fixed an identical problem in Apache Traffic Server last year. (You don't have an ATS instance before your sites, do you?)
I don't, unfortunately, know how to disable the Apache error. It is a real error -- this is a protocol violation (on their side) and Apache is sending back 400 Bad Request to these clients.
Info on the (fixed) comparable ATS failure mode: https://issues.apache.org/jira/browse/TS-4468
Short answer: No.
Long answer: I had a quick gander at the source and those errors are being logged unconditionally in ssl_engine_kernel.c. So short of a patch to Apache, your best options would be some sort of post-processing of the log or using a CustomLog directive to pipe the log output to a program of your choice to remove the clutter. The latter is obviously potentially quite expensive and seems like overkill, but hey, there's no nice options anyway!
Hi Jamie,
Going to ask the dev team to look into this. Will report back.
-Edwin
Thank you!
Have you ever considered some form of log consolidation and manipulation? There has to be dozens of these annoyances. They surely pop up again once you slap them down (hail hydra).
I doubt there will always be a follow up from someone that reads the blog and happens to work at fucking_up_tech_behemoth of the week so it seems sensible to be proactive.
Something like Gray Log combined with Elastic Search would probably make your life a lot easier. I know you greet the idea of more shit to maintain and faff about with, with all the enthusiasm of cleaning up a dog turd; but for once short term pain might be worth it. It would solve this problem and actually make monitoring and searching logs from the no doubt legion of various systems you have quite a bit less annoying.
Look, I'm just an unfrozen caveman, I monitor my logs by having a shell buffer with tail -f running on the three Apache error_log files that I sometimes care about. Anything that requires more maintenance than that is crazy talk.
Lowercase f? Caveman indeed. Maybe try an uppercase F and join the, I'm going to guess 1990s ? That way when the logs are rolled tail rolls along with them.
tail -f | grep -v? :P