0

Using a fairly typical/standard Apache installation on Ubuntu, with mod_ssl enabled, every "so often" (random time period) a website on the server stops responding.

When looking to see why, I noticed that /etc/apache2/mods-enabled/ssl.conf and ssl.load are missing. Using these two commands, I can immediately bring the website back up:

a2enmod ssl
service apache2 restart

It is infuriating! There must be a conflict somewhere, but I cannot figure out where.

Ubuntu 14.04 LTS Apache 2.4.7

Virtual Host Config File (/etc/apache2/sites-enabled/my-domain.org.conf)

<IfModule mod_ssl.c>
<VirtualHost xxx.xxx.xxx.xxx:443>
    ServerName              my-domain.org
    ServerAlias             www.my-domain.org
    ServerAdmin             null@foo.tld

    DocumentRoot            /var/www/my-domain.org

    SSLEngine               on
    SSLCertificateKeyFile   /etc/letsencrypt/live/my-domain.org/privkey.pem
    SSLCertificateFile      /etc/letsencrypt/live/my-domain.org/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/my-domain.org/chain.pem

    CustomLog               /var/log/apache2/my-domain.org/ssl_access_log vhost_combined
    ErrorLog                /var/log/apache2/my-domain.org/ssl_error_log

    <Directory /var/www/my-domain.org>
            Options         -ExecCGI -Indexes -Includes +FollowSymLinks
            AllowOverride   FileInfo AuthConfig

            RewriteEngine   On
            RewriteBase     /

            RewriteCond     %{HTTP_HOST} ^www\.(.*)$ [NC]
            RewriteRule     ^/(.*)$ https://%1/$1 [R=301,L]

            php_admin_flag  engine on
            php_admin_flag  display_startup_errors on
            php_admin_flag  display_errors on
            php_admin_flag  html_errors on
            php_admin_flag  log_errors on
            php_admin_flag  ignore_repeated_errors off
            php_admin_flag  ignore_repeated_source off
            php_admin_flag  report_memleaks on
            php_admin_flag  track_errors on

            php_value       memory_limit 32M
    </Directory>
</VirtualHost>
</IfModule>

Log output from /var/log/apache2/my-domain.org/ssl_error_log:

[13:35:29.822335] [mpm_prefork:notice] [pid 2043] AH00169: caught SIGTERM, shutting down
[13:35:30.867258] [auth_digest:notice] [pid 2725] AH01757: generating secret for digest authentication ...
[13:35:30.896369] [mpm_prefork:notice] [pid 2725] AH00163: Apache/2.4.7 (Ubuntu) PHP/5.5.9-1ubuntu4.21 OpenSSL/1.0.1f configured -- resuming normal operations
[13:35:30.896406] [core:notice] [pid 2725] AH00094: Command line: '/usr/sbin/apache2'

There doesn't seem to be anything wrong there.

conspireagainst
  • 1
  • 2
  • Can you provide some output from your logs, showing what the server is doing around the time the issue shows up (e.g. before you restart)? Is there anything on the system that could be causing this, such as a configuration management tool (or another admin)? – iwaseatenbyagrue Apr 10 '17 at 16:31
  • I added the SSL log Apache generates, well three lines from it since those are the only things in there and keep repeating. The only "tool" is Nagios. I've never had a problem with SSL until now, years running this server. I decided to use LetsEncrypt instead of purchasing a certificate, and this is when things started. – conspireagainst Apr 10 '17 at 17:22
  • Ok - is there any way this could be linked to LetsEncrypt? How do you renew/update/install your certs (i.e. which tool), how often does that tool run, and do the runs correlate to any of your issues? It sounds like `certbot --apache` might be a possible cause – iwaseatenbyagrue Apr 10 '17 at 17:32
  • I have installed the certificate once, and it hasn't been 90 days yet so have not setup renewal or automation. I did use `certbot certonly` as the --apache just never worked. Could this really be an issue with the certificates themselves? As in, some negotiation is failing and Apache is booting the modules due to that? – conspireagainst Apr 10 '17 at 19:08

2 Answers2

0

Let's Encrypt installs itself with automated certificate expiration checking and attempt(s) to self-renew. This would be ideal, if it worked. However, the scripts will only work properly if it does not encounter what it considers to be Apache issues/conflicts.

Initially, I tried to use Let's Encrypt's automated installation process: certbot --apache

It never worked properly, so I settled for certbot certonly. Regardless of the process, it still was attempting to automate certificate renewal and failing. Now, I'm not sure exactly how the whole thing works, but here's the fix:

Find the domain's configuration file at /etc/letsencrypt/renewal/my-domain.org.conf and comment everything out. I assume the automated processes will work if --apache ever gets its act together. For now, I don't necessarily need it to self-renew as it can be manually done.

I hope this helps someone. It surely helped me.

conspireagainst
  • 1
  • 2
-1

Please provide your log lines from just before your restart.

It is possible your SSL access log can be in different folder. Also if you SSL.conf file is under a sub folder please check their permissions when the failure happens.

These are some basic things you could check. Some times the mod_ssl lib wont just play nice, look into the version if they have any reputation with bugs etc.

Also could this be by traffic conjestin.. That is all i could think now..

8080HouseFul
  • 1
  • 1