I have three load-balanced Apache 2.4.6 servers running on fresh installs of CentOS 7. The load-balancer is a Barracuda 340. I know its old, but it's more than capable of handling the traffic, and everything is working great with the actual site that they are hosting. All servers are NATed behind a firewall and don't have public IP addresses. However, exactly every thirty seconds, I see the same 3 SSL errors in my Apache Logs. In the following logs, sub.example.com represents a subdomain which is different from that actually being hosted by the servers in question. And 10.0.0.123 is the IP address of the load-balancer on the internal network.
[Fri May 01 06:28:37.315078 2015] [ssl:info] [pid 13873] [client 10.0.0.123:37617] AH01964: Connection to child 5 established (server sub.example.com:443)
[Fri May 01 06:28:37.315175 2015] [ssl:debug] [pid 13873] ssl_engine_io.c(1201): (70014)End of file found: [client 10.0.0.123:37617] AH02007: SSL handshake interrupted by system [Hint: Stop button pressed in browser?!]
[Fri May 01 06:28:37.315183 2015] [ssl:info] [pid 13873] [client 10.0.0.123:37617] AH01998: Connection closed to child 5 with abortive shutdown (server sub.example.com:443)
If I was having trouble actually negotiating the connection with the site being hosted, I'd have something to go on, but the actual site works perfectly. I just don't want my error logs filled with garbage. Any help is much appreciated.
Best Answer
Check if sub.example.com resolves to the same IP address as example.com (or at least one of the IP of the load balancer). If this is the case then somebody might try to access the wrong site but stop during the SSL handshake because the certificate does not match the accessed URL. Since the message repeats every 30 seconds it might be some kind of automatism which might have worked in the past and maybe stopped working after changes to your site. It might have also stopped working after changes on the clients side, because several script languages and tools now check the certificate by default and did not check it in the past.
To detect the origin of the client you'll probably have to look into log files or do packet captures on strategic places to find out the clients IP. If you have access to the DNS settings you might also simply point sub.example.com to nowhere.