Apache SSL Errors every 30 seconds

Question

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.

Solution 1

In the following logs, sub.example.com represents a subdomain which is different from that actually being hosted by the servers in question.

[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?!]

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.

Solution 2

Sounds like the load balancer is probing for active ports .. but not negotiating till the end as apache would expect .. nothing to worry about ..

Maybe you can change probing mechanism on the LB to fetch some real URL?

Comments

[spuy767]

The SSL sert is a wildcard for *.mydomain.com, and both addresses are in that format. The DNS for sub.mydomain.com resolves to a different IP which is another load-balanced group of servers in a different physical location. As for the DNS, we host that server and both domain names need to be up. We can't simply point it to nowhere.

[Steffen Ullrich]

If I understand you right then somebody is accessing sub.example.com by using a IP address which does not belong to sub.example.com? And BTW, please stick to names reserved for examples (example.com, example.org...) and don't use existing names which don't belong to you.

[spuy767]

I had Debug level logging on because this configuration is currently for testing, normally I run LogLevel at notice unless Something goes wrong that I need to trouble shoot. I'm not going to sweat the errors because they don't appear to have any effect on the operation of the site. Thanks for your help, but given the circumstances, it would be nigh on impossible for anyone to be accessing that server at sub.example.com.