0

So once in a while I receive an email about apache being unreachable. I mean it actively rejects connections (ERR_CONNECTION_REFUSED for Chrome). 

systemctl status apache2
● apache2.service - The Apache HTTP Server
   Loaded: loaded (/lib/systemd/system/apache2.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Tue 2020-06-09 14:36:58 CEST; 8min ago
  Process: 2533 ExecStop=/usr/sbin/apachectl stop (code=exited, status=0/SUCCESS)
  Process: 4325 ExecReload=/usr/sbin/apachectl graceful (code=exited, status=0/SUCCESS)
  Process: 20597 ExecStart=/usr/sbin/apachectl start (code=exited, status=0/SUCCESS)
 Main PID: 20603 (code=exited, status=0/SUCCESS)

Syslog

Jun  9 14:36:01 f CRON[2494]: (www-data) CMD (php /var/www/avg.php)
Jun  9 14:36:57 f systemd[1]: Starting Certbot...
Jun  9 14:36:58 f apachectl[2533]: httpd (no pid file) not running
Jun  9 14:37:01 f CRON[2544]: (www-data) CMD (php /var/www/avg.php)
Jun  9 14:37:25 f systemd[1]: Started Certbot.
Jun  9 14:37:25 f systemd[1]: certbot.timer: Adding 2h 47min 35.570277s random time.
Jun  9 14:37:25 f systemd[1]: certbot.timer: Adding 1h 45min 16.226705s random time.

The last second apache were running and logging was at 09/Jun/2020:14:36:02 (it is server which receives a bunch of requests from cron from other servers once a minute, so it is totally cool that there was no log entry during the last minute).

I tried upgrading certbot but it seems it is in the last possible version. 

certbot is already the newest version (0.28.0-1~deb9u2).
python-certbot-apache is already the newest version (0.28.0-1~deb9u1).

This didn't happen for the first time and I didn't find much online. What are the next steps I could do to find the caveat?

EDIT: /var/log/letsencrypt.log 

2020-06-09 14:36:58,199:INFO:certbot.hooks:Running pre-hook command: apachectl -k stop
2020-06-09 14:36:58,250:INFO:certbot.main:Renewing an existing certificate

at the end

2020-06-09 14:37:25,395:DEBUG:certbot.renewal:no renewal failures
2020-06-09 14:37:25,395:INFO:certbot.hooks:Running post-hook command: apachectl -k start

Is there a way to configure certbot not using port 80 but rather some else so I don't need my apache to stop during renewal (and in the worst time possible)?

Improve this question

3 Answers 3

Reset to default
1

As Рамиль Матрасов mentioned, you have configured Certbot to run its own webserver i.e. in the standalone plugin, while you should have been using the webroot plugin, instead. Your configuration causes Certbot to stop Apache so that it can bind to port 80. Also, the DNS-01 challenge suggested by Henrik Pingel seems unnecessarily complicated for your use case.

Webroot

If you’re running a local webserver for which you have the ability to modify the content being served, and you’d prefer not to stop the webserver during the certificate issuance process, you can use the webroot plugin to obtain a certificate by including certonly and --webroot on the command line. In addition, you’ll need to specify --webroot-path or -w with the top-level directory (“web root”) containing the files served by your webserver.

However, showing what you should have done doesn't really help you solving the current problem: you can also change the current settings by modifying the configuration files in /etc/letsencrypt/renewal. E.g. in example.com.conf you might currently have:

[renewalparams]
authenticator = standalone
webroot_path = /home/letsencrypt,
[[webroot_map]]
example.com = /home/letsencrypt
www.example.com = /home/letsencrypt

Replace the authenticator = standalone with authenticator = webroot for every configuration file and also check that the webroot_path or maps match the ones you have in your Apache <VirtualHost>s, e.g.

[renewalparams]
authenticator = webroot
[[webroot_map]]
example.com = /var/www/example.com
www.example.com = /var/www/example.com

You can test your new configuration with certbot renew --dry-run.

Improve this answer
2
  • Is there a way to do a wildcard without a DNS challenge? Haha you perfectly answered the question I just thought about from reading the other guy's answer :-)
    – Martin.
    Jun 11, 2020 at 18:07
  • DNS-01 challenge is required for wildcard certificates. That's an inevitable security decision: you wouldn't want just any webhosting.example.com to be able to get certificates for your entire domain.
    – Esa Jokinen
    Jun 12, 2020 at 13:51
2

you have misconfigured certbot, certbot can use apache as web server to handle AMCE-challenge.. and you configured it to use his own embedded web server. you should do like this:

./certbot-auto certonly --webroot -d host.example.com --webroot-path /var/www/html

when you done it once, then just crontab this:

certbot-auto renew

this config will use /var/www/html to create .well-known dir with challenge and use your apache.

Improve this answer
1
  • How do I do this in the actual configuration for these pages? Will it overwrite the old config after I run this command?
    – Martin.
    Jun 11, 2020 at 18:05
1

Configure certbot to use DNS-01 challenge instead of HTTP-01 challenge.

Improve this answer
4
  • How can that work considering you have to change a DNS record for that, don't you?
    – Martin.
    Jun 11, 2020 at 18:03
  • That method works by adding a TXT record to DNS. There is no need to change the A record. However in this case I would recommend you to debug and fix the issues with certbot and stick with http-01. In any way it is an option if your dns provider is supported by certbot. The list of supported dns providers is listed in the linked documentation.
    – Henrik Pingel
    Jun 11, 2020 at 18:18
  • But that TXT record have to change every few months when renewing.
    – Martin.
    Jun 11, 2020 at 22:02
  • That is supposed to be done by certbot. No matter which challenge method used it is not the worst idea to configure a cron job for certbot.
    – Henrik Pingel
    Jun 12, 2020 at 8:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .