Challenge Failed for domain

Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g., so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is:

I ran this command:
sudo certbot certonly --dry-run
It produced this output:
Saving debug log to /var/log/letsencrypt/letsencrypt.log

How would you like to authenticate with the ACME CA?

1: Apache Web Server plugin (apache)
2: Spin up a temporary webserver (standalone)
3: Place files in webroot directory (webroot)

Select the appropriate number [1-3] then [enter] (press ‘c’ to cancel): 1
Plugins selected: Authenticator apache, Installer None
Please enter in your domain name(s) (comma and/or space separated) (Enter ‘c’
to cancel):
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for
Enabled Apache rewrite module
Waiting for verification…
Challenge failed for domain
http-01 challenge for
Cleaning up challenges
Some challenges have failed.


  • The following errors were reported by the server:

    Type: connection
    Detail: Fetching
    Error getting validation data

    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
Server version: Apache/2.4.41 (Ubuntu)
Server built: 2020-04-13T17:19:17

The operating system my web server runs on is (include version):
ubuntu server 64 bit ver
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04 LTS
Release: 20.04
Codename: focal

My hosting provider, if applicable, is:
my house, raspberry pi 3

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):
phpmyadmin Version information: 4.9.5deb2

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

i’ve checked that it is accessible from outside my network i’ve also checked my firewall.

also found that apache is super hard to kill now and service apache2 stop doesn’t stop it right away i have to go in manually and kill it

root@ubuntu:/var/www/html# ps aux | grep apache
root 3163 0.0 2.9 223140 27284 ? Ss Jun16 0:01 /usr/sbin/apache2 -k graceful
www-data 4190 0.0 1.8 256404 16960 ? Sl 00:24 0:00 /usr/sbin/apache2 -k graceful
www-data 4191 0.0 1.8 256404 16960 ? Sl 00:24 0:00 /usr/sbin/apache2 -k graceful
www-data 4192 0.0 1.8 256404 16900 ? Sl 00:24 0:00 /usr/sbin/apache2 -k graceful
www-data 4200 0.0 1.7 256356 16312 ? Sl 00:24 0:00 /usr/sbin/apache2 -k graceful
www-data 4202 0.0 1.7 256356 16312 ? Sl 00:24 0:00 /usr/sbin/apache2 -k graceful
root 4249 0.0 0.0 7684 644 pts/0 S+ 00:31 0:00 grep --color=auto apache
root@ubuntu:/var/www/html# kill 3163
root@ubuntu:/var/www/html# ps aux | grep apache
root 4251 0.0 0.0 7684 692 pts/0 S+ 00:32 0:00 grep --color=auto apache
root@ubuntu:/var/www/html# kill 4251
bash: kill: (4251) - No such process

1 Like

Apache is notorious for running at all costs.
Which means that although it may be running the config may not be exactly correct.
Certbot will do its’ best to understand and use the Apache config and modify it accordingly.
But it is not human, nor psychic, so it can make mistakes and can be confused by what it finds.
So maybe some humans should have a look at what is there and see why certbot is failing.
Let’s start with the output of:
apachectl -S

1 Like

I had a very similar problem when I first started to use certbot. The apache server needs to be able to access the directory {server_root}/.well-known, and it is not smart enough to create that directory if it does not exist. So you will probably need to create that directory, and then make it writable by apache (I set the group for .well-known to httpd, and the mode to 660). Once the directory is there, the HTTP-01 module in certbot knows enough to create the acme-challenge files inside that folder, so that the remote certificate site can see them.

1 Like

just so i understand this correctly where would i need to make this folder?

looking online all i see are tutorials for everything but ubuntu server + apache

unless im misunderstanding server_root which is totally probable

1 Like

wait i think i got it now.

i did
ubuntu@ubuntu:/var/www/html$ mkdir .well-known
mkdir: cannot create directory ‘.well-known’: File exists
ubuntu@ubuntu:/var/www/html$ chmod +660 .well-known/
ubuntu@ubuntu:/var/www/html$ ls

so it was already there but i just changed options. i don’t see it when i LS though i assume that’s a permissions thing

running ls -a
i see

root@ubuntu:/var/www/html# ls -a
. index.php wp-admin wp-config.php wp-links-opml.php wp-settings.php
… license.txt wp-blog-header.php wp-content wp-load.php wp-signup.php
.htaccess readme.html wp-comments-post.php wp-cron.php wp-login.php wp-trackback.php
.well-known wp-activate.php wp-config-sample.php wp-includes wp-mail.php xmlrpc.php

1 Like

hahaha i like the way you put it.
here’s the output

ubuntu@ubuntu:~$ apachectl -S
VirtualHost configuration:
*:80 localhost (/etc/apache2/sites-enabled/000-default.conf:1)
ServerRoot: “/etc/apache2”
Main DocumentRoot: “/var/www/html”
Main ErrorLog: “/var/log/apache2/error.log”
Mutex ssl-stapling-refresh: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/run/apache2/" mechanism=default
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
PidFile: “/var/run/apache2/”
User: name=“www-data” id=33 not_used
Group: name=“www-data” id=33 not_used


That looks correct, up to the point where you displayed the directory contents for /var/www/html. If you do
ls -l .well-known
you should see that the user and group are root/httpd. If not, you will need to do
chown root.httpd .well-known
to make the directory writable by apache

1 Like

okay so running
ubuntu@ubuntu:/var/www/html$ ls -l .well-known

i get

total 0

then running

ubuntu@ubuntu:/var/www/html$ chown root.httpd .well-known

i get
chown: invalid user: ‘root.httpd’

would i just remove the httpd to make it a valid user ‘root’?

1 Like

Sorry. I mistyped. The specification should be root:httpd, not root.httpd. Check the man page for chown to find out more details.

1 Like

i don’t seem to have an httpd user

these are the list of users i have

httpd is the “user of apache” though so i’m curious as to why it isn’t showing up

either way chown root:httpd .well-known didn’t work as it’s saying it’s an invalid group

I think you might be chasing a red herring…

I would start by creating a specific config for the name intended to be secured.
Start with a working:
and then we can work on securing it.
All I see now is a default (catch all) config:

1 Like

Apologies for the ignorance,
But how would I go about doing that?

I thought it was considered a bad thing (in my limited Apache experience) to mess with sites-enabled. Or are you saying I should create a file within sites-available called

Thankyou for your persistence

1 Like

You should follow the most basic steps to create and enable a dedicated vhost config for your site name.

That is the usual place to start.
Then you will need to enable it.
Then test that it is actually available from the Internet.
Then you can try to secure it.

[the actual name of the file (on disk) would not include http:// and would probably end with .conf]
so maybe something like: /etc/apache/sites-available/

1 Like

Good morning Rudy,
i created the

copied the config over from 000-default-conf
restarted apache
apache failed to start

i also tried creating this loadout but it never was able to start
<VirtualHost *:80>

Redirect permanent /

<VirtualHost *:443>
DocumentRoot /var/www/html

Protocols h2 http:/1.1

<If “%{HTTP_HOST} == ''”>
Redirect permanent /

ErrorLog {APACHE_LOG_DIR}/ CustomLog {APACHE_LOG_DIR}/ combined

SSLEngine On
SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
SSLOpenSSLConfCmd DHParameters “/etc/ssl/certs/dhparam.pem”

SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCompression off
SSLUseStapling on

<Directory /var/www/html>
Options FollowSymlinks
AllowOverride All
Require all granted

<Directory /var/www/html>
RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*) index.php [PT,L]

still was unable to create the ssl cert.

one thing i did find interesting though is that reading the issue

.reading that directory (in /var/www/html) i see no files in it whatsoever but the directory is there.

would that mean that certbot is unable to write to it / is a permission issue?

or does certbot auto remove the files when it fails?

1 Like

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