7

I have installed a self-signed SSL certificate for the website I am running on localhost. It seems that the data reaching the browser is complete and correct for both the SSL and non-SSL versions, but I am getting a lot of apache error output which seems to indicate otherwise.

When I hit refresh, I immediately get a couple of these lines in the log

AH01964: Connection to child 0 established

Also child 2, 6, 4, etc may appear, in no particular order.

Over the next few seconds I get several of these

(70014)End of file found: [client 127.0.0.1:32839] AH01991: SSL input filter read failed.
[client 127.0.0.1:32840] AH01382: Request header read timeout

I assume the multiplicity of these lines is due to scripts, css, etc because if I go to 'View Source' and refresh that window, I get one of these

AH01964: Connection to child 4 established

...and nothing else. All this happens for https connections only. The log for http is silent.

Is anything actually wrong? I repeat, the content seems to be completely and correctly served, which seems to contradict the "read failed" and "timeout" language in the log. Are these errors just noise or do I have to fix something?

If they're just harmless noise, how do I turn them off?


Here is how I set everything up. (I got this process piecewise from various tutorials without fully understanding it.)

In /etc/hosts I have

127.0.0.1 x.com

I created a self-signed ssl certificate via the following script

openssl genrsa -des3 -out x.com.key 2048
openssl req -new -key x.com.key -out x.com.csr
cp x.com.key x.com.key.org
openssl rsa -in x.com.key.org -out x.com.key
openssl x509 -req -days 3650 -in x.com.csr -signkey x.com.key -out x.com.crt
chmod 400 x.com.{key,crt,csr}
sudo chown www-data x.com.{key,crt,csr}
sudo mv x.com.{key,crt,csr} /path/to/website/

During this process I input

Common Name (e.g. server FQDN or YOUR name) []:x.com

I have both a <VirtualHost x.com:80> and a <VirtualHost x.com:443> set up in sites-enabled/000-default.conf and the difference between them is this section:

SSLEngine on
SSLCertificateFile /path/to/website/x.com.crt
SSLCertificateKeyFile /path/to/website/x.com.key
SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
CustomLog ${APACHE_LOG_DIR}/x.com.ssl.log "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

And they have this in common:

LogLevel info
spraff
  • 549
  • 4
  • 8
  • 18

4 Answers4

7

As others have said, these messages are logged because your LogLevel is set to info. If you don't want these specific messages, but still want info level logs, you can reconfigure this in your apache config:

LogLevel info ssl:warn

  • 1
    Error: LogLevel takes one argument, Level of verbosity in error logging (apache-2.2.32). This option is only available for Apache 2.3 and above. See https://serverfault.com/a/158369/120479 – Will Sheppard May 19 '17 at 14:19
3

This question appears to be the same as this one, which obviously I found while diagnosing the same thing.

The issue is caused by setting a name based (or wildcard catchall) to a VirtualHost instead of an IP address. The problem is that the domain name is only passed to a web server once the connection is established, by which stage the SSL/TLS connection must already be active, so the server needs to select the correct SSL key based on the minimum information available and that is the IP address for that virtual host.

There is greater detail and sample configuration information on the Apache website, but basically you want to change the <VirtualHost x.com:443> to <VirtualHost 1.2.3.4:443> where that uses the IP address for that host/interface.

Ben
  • 146
  • 5
  • 1
    [Newer Apache versions have SNI](http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts2) which allows multiple VirtualHosts on the same IP, so the wildcard virtualhost should work. But alas, these info messages persist. – partofthething Nov 17 '15 at 06:16
  • Wow! I have been wondering about this one for a while. I put the IP address instead of the wild card (`*:443`) and it quite down the warnings. – Alexis Wilke Aug 03 '16 at 01:54
  • Indeed, this is the reason. Even though 2.4 supports SNI, if there are too many requests coming at the same time, it seems it may fail at times to match the domain to the cert. When i changed * to the ip of the interface, requests/sec to a https:// url increased on average 50%, and no such ssl connect errors ended up happening. – unity100 Jun 06 '19 at 11:26
  • 1
    This answer is not correct. I have Apache 2.2.15 set up with , and my logs are full of these errors. – joe Dec 01 '19 at 03:27
1

LogLevel info is most likely the cause, and it definitely looks like harmless noise.

Any particular reason you need the logging set to that verbose, or can you dial it back to something like notice or warn?

Shane Madden
  • 114,520
  • 13
  • 181
  • 251
  • 3
    Yes I can reduce the log level but a) I do want some info-level messages, and b) they seem to be saying something's wrong. I don't want to brush it under the carpet. – spraff Jan 08 '14 at 12:58
0

Check your configs into version control: rcs http://pages.cs.wisc.edu/~plonka/sysadmin/article.html

cd /etc/

rcs -ci *.cnf,config,.conf

L Kachold
  • 1
  • 2