Certbot challenge failed

Help
1

I'm unable to get a certificate.

My domain is: phoenixave.com

I ran this command: sudo certbot --apache

It produced this output:

Saving debug log to /var/log/letsencrypt/letsencrypt.log
ssl_module is statically linked but --apache-bin is missing; not disabling session tickets.

Which names would you like to activate HTTPS for?
We recommend selecting either all domains, or all domains in a VirtualHost/server block.

1: phoenixave.com

Select the appropriate numbers separated by commas and/or spaces, or leave input
blank to select all options shown (Enter 'c' to cancel): 1
Requesting a certificate for phoenixave.com

Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Identifier: phoenixave.com
Type: unauthorized
Detail: 74.104.194.221: Invalid response from http://phoenixave.com/.well-known/acme-challenge/psIXofk2urg_TgWG6R9JRTRAVL0TNlyPwSM60ISMKKY: 404

Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.

Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.

My web server is (include version): Apache/2.4.62 (Unix)

The operating system my web server runs on is (include version): MacOS 26.3.1

My hosting provider, if applicable, is: n/a

I can login to a root shell on my machine (yes or no, or I don't know): yes

I'm using a control panel to manage my site (no, or provide the name and version of the control panel): no

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): certbot 5.4.0

It's unclear to me where certbot is trying to put the .well-known directory (I was expecting it to tell me with --verbose, but it didn't).

When I run apachectl -t -D DUMP_VHOSTS I get:

VirtualHost configuration:
*:80 phoenixave.com (/opt/homebrew/etc/httpd/extra/httpd-vhosts.conf:23)

1 Like
2

Welcome @mwessler

A 404 error using the --apache authenticator is unusual. It is almost always because there is some incompatible Apache config. The 404 is an HTTP Not-Found error. It means Certbot prepared your system to reply to the HTTP Challenge. But, when the Let's Encrypt server sent that challenge your server said it couldn't find the token to reply.

Would you show the contents of
/opt/homebrew/etc/httpd/extra/httpd-vhosts.conf

2 Likes
3 
# Virtual Hosts
#
# Required modules: mod_log_config

# If you want to maintain multiple domains/hostnames on your
# machine you can setup VirtualHost containers for them. Most configurations
# use only name-based virtual hosts so the server doesn't need to worry about
# IP addresses. This is indicated by the asterisks in the directives below.
#
# Please see the documentation at
# <URL:http://httpd.apache.org/docs/2.4/vhosts/>
# for further details before you try to setup virtual hosts.
#
# You may use the command line option '-S' to verify your virtual host
# configuration.

#
# VirtualHost example:
# Almost any Apache directive may go into a VirtualHost container.
# The first VirtualHost section is used for all requests that do not
# match a ServerName or ServerAlias in any <VirtualHost> block.
#
<VirtualHost *:80>
    ServerName phoenixave.com
    DocumentRoot /Users/wessler/www/phoenixave

    <Directory /Users/wessler/www/phoenixave>
        Require all granted
	AllowOverride all
    </Directory>
</VirtualHost>
4

Just as a test would you show output of this command?

sudo certbot certonly --dry-run --webroot -w /Users/wessler/www/phoenixave -d phoenixave.com
2 Likes
5 
> sudo certbot certonly --dry-run --webroot -w /Users/wessler/www/phoenixave -d phoenixave.com
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account registered.
Simulating a certificate request for phoenixave.com
The dry run was successful.
6

Alright. We have two options

Continue using --webroot (instead of --apache) which we know works. We can use a --deploy-hook to automatically reload Apache whenever you get a new cert. However, you will need to configure your own VHost for port 443 for HTTPS. The --apache option will create one for you but --webroot does not. It creates one using your port 80 VHost items along with "Interemediate" options from the Mozilla SSL Configurator: https://ssl-config.mozilla.org/

Do not choose HSTS unless you are certain of the implications. And, no need to enable OCSP stapling as Let's Encrypt now uses CRL rather than OCSP.

Debug why --apache option failed. This involves looking at your entire Apache config and Certbot logs to see what is not compatible. It is possible once this is identified the best alternate solution is still to use --webroot so there is no guarantee. Your setup looks fairly simple and with a current Certbot version a 404 failure is very unusual.

Let us know how you want to proceed.

2 Likes
7

I tried the --webroot version and it does work, but I do agree that it would be nice if --apache worked. What would be the next step for debugging --apache? What do you need from https.conf or the certbot logs?

8

Well, I personally do not prefer the --apache option so don't "agree" :slight_smile: I prefer to manage my Apache config rather than having another program do that.

And, for that matter, for Apache I prefer the mod_md ACME Client that is built-in directly to Apache rather than using a stand-alone ACME Client.

That all said, to debug --apache failure we'd need to see all of the Apache config files and a Certbot log from a failed run. And, it may become time-consuming to try different things to isolate the incompatibility. I don't have a lot of time for such an effort today but perhaps another volunteer will. I may have time later to look at your config if you post it but not much time to experiment.

2 Likes
9

In that case, what's the best way to automate the restart of the server if the certificates change?

10

By adding an option like --deploy-hook "apachectl -k graceful"

But using the command best suited for your case

2 Likes
11

thanks!

2 Likes