Apache becomes unresponsive when running certbot

Since upgrading from ubuntu 18.10, apache became unresponsive every day, requiring a restart of the apache service to make it work again. Apache error log is then spammed with:

[Tue Nov 06 00:00:06.523969 2018] [core:error] [pid 17329] AH00546: no record of generation 0 of exiting child 24954
[Tue Nov 06 00:00:06.524015 2018] [core:notice] [pid 17329] AH00051: child pid 24955 exit signal Segmentation fault (11), possible coredump in /etc/apache2

I’ve narrowed the problem down to certbot, and I can reproduce it by running certbot --apache.

When running certbot, the apache logs will also contain the following entries:

[Tue Nov 06 08:25:04.991613 2018] [mpm_prefork:notice] [pid 25264] AH00171: Graceful restart requested, doing restart
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
AH00112: Warning: DocumentRoot [/var/lib/letsencrypt/tls_sni_01_page/] does not exist
AH00558: apache2: Could not reliably determine the server’s fully qualified domain name, using Set the ‘ServerName’ directive globally to suppress this message
[Tue Nov 06 08:25:05.334889 2018] [ssl:warn] [pid 25264] AH01906: 9fb61462685251450e8beac7a5a4917d.27cc1ef6e6d55acaf1e478e0a46f6b1c.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Tue Nov 06 08:25:05.335955 2018] [ssl:warn] [pid 25264] AH01906: 0a5476ddd68cfcf5a4061a1c6cb2fbc3.b080bc01f066e755ce11a4e2d87e045e.acme.invalid:443:0 server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)

My domain is:

I ran this command:
sudo certbot --apache

It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator apache, Installer apache

Which names would you like to activate HTTPS for?

1: bragi.timalkemade.nl

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter ‘c’ to cancel):
Obtaining a new certificate
Performing the following challenges:
tls-sni-01 challenge for bragi.timalkemade.nl
Waiting for verification…
Cleaning up challenges
Failed authorization procedure. bragi.timalkemade.nl (tls-sni-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Timeout during connect (likely firewall problem)


  • The following errors were reported by the server:

    Domain: bragi.timalkemade.nl
    Type: connection
    Detail: Timeout during connect (likely firewall problem)

    To fix these errors, please make sure that your domain name was
    entered correctly and the DNS A/AAAA record(s) for that domain
    contain(s) the right IP address. Additionally, please check that
    your computer has a publicly routable IP address and that no
    firewalls are preventing the server from communicating with the
    client. If you’re using the webroot plugin, you should also verify
    that you are serving files from the webroot path you provided.

My web server is (include version):
Apache/2.4.34 (Ubuntu)
The operating system my web server runs on is (include version):
Ubuntu 18.10
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don’t know):
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):

Hi @MakeTimeLad

you have a new Letsencrypt certificate, created today. So it works.


The tls-sni-01 challenge is deprecated. Support ends 2019-02...

So next time switch to http - validation.

--preferred-challenges http

To make sure my site works again, I stopped apache and created a new one using the certbot certonly --standalone command. I’ll try to see if ‘–preferred-challenges http’ validation fixes the issue for --apache.

I just tried with --preferred-challenges http. Letsencrypt gave me a new certificate, but still made apache unresponsive afterwards.

After more investigation, the problem appears to be in apache itself. I haven’t found a solution yet, but for some reason the apachectl graceful command causes the issue. I’ll close this thread.

1 Like

I fixed the problem, in case anyone else has the same issue. I was running with php 7.2 packages, but for some reason, the php7.0 module was enabled in apache. Uninstalling the php7.0 module and installing the the php7.2 module fixed the issue.


Thanks, good to know. If someone else has the same problem.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.