Sobchak and I just fixed a problem that had crept into one of our internal webservers and I wanted to capture it because it was an interesting problem and might help some folks out there. He had recently (Last Thursday) added a very straightforward virtual host for something called tsf with no fanfare. There is another site on that box, running Redmine, with a far less straightforward config. Being a Ruby on Rails site, the Apache end of the config sets up a proxy balancer to a small number of mongrel processes.

I had used Redmine to retrieve something from the wiki last week, but access to Redmine is infrequent these days as we’ve moved on to another ticketing system.

When I went to retrieve some ticket notes from redmine today, I was presented with an ssl error from all browsers.

Chrome:

SSL connection error
Unable to make a secure connection to the server. This may be a problem with the server, or it may be requiring a client authentication certificate that you don't have.
Error 107 (net::ERR_SSL_PROTOCOL_ERROR): SSL protocol error.

Firefox:

Secure Connection Failed

An error occurred during a connection to *********************.

SSL received a record that exceeded the maximum permissible length.

(Error code: ssl_error_rx_record_too_long)

The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.

IE:

Internet Explorer cannot display the webpage
What you can try:

Diagnose Connection Problems

More information

This problem can be caused by a variety of issues, including:
•Internet connectivity has been lost.
•The website is temporarily unavailable.
•The Domain Name Server (DNS) is not reachable.
•The Domain Name Server (DNS) does not have a listing for the website's domain.
•There might be a typing error in the address.
•If this is an HTTPS (secure) address, click Tools, click Internet Options, click Advanced, and check to be sure the SSL and TLS protocols are enabled under the security section.
[snip]

We had a hard time understanding why the addition of the tsf.blah.blah virtual host would have caused redmine (vhost rm.blah.blah) to die. We verified that disabling the tsf site and restarting apache2 caused redmine to work again, so that must be the culprit. However, the config was essentially a copy of another older WordPress site (nfarch.blah.blah) that was NOT interfering with redmine’s existence.

Then it occurred to me: if apache2 processes vhost configs in the conf.d directory in alphabetical order, it would do nfarch, then rm, then tsf. Which means, tsf could totally be clobbering something for redmine when nfarch did not.

tsf vhost configs started with

NameVirtualHost *
<VirtualHost *>

Well what do you know? Could that be overriding the *:443 in the redmine vhost config? We changed that to:

NameVirtualHost *:80
<VirtualHost *:80>

I am not an apache expert, but that completely fixed our issue. Hope that helps someone else searching for answers–most of what I found in my googling was related to client-side problems, not server-side problems.