Http-01 challenge fails

I’m at my wits end. I recently had no trouble getting certificates for two of my other domains (,, but when trying to expand to include the following domain, I get the following error. I have also added

location ^~ /.well-known/acme-challenge/ {
allow all;
root /var/lib/letsencrypt/;
default_type “text/plain”;
try_files $uri =404;


as a snippet into the nginx config for that domain, but doesn’t seem to work either. Seems like a common and recent-ish problem, but trying to different suggestions in those topics didn’t work for me. The above snippet isn’t in the configs for my other domains (but worked anyway, prior to this past week).

I’m not really sure what else I can do to troubleshoot.

My domain is:

I ran this command: sudo certbot --nginx

It produced this output:
Renewing an existing certificate
Performing the following challenges:
http-01 challenge for
http-01 challenge for
Waiting for verification…
Challenge failed for domain
Challenge failed for domain
http-01 challenge for
http-01 challenge for
Cleaning up challenges
Some challenges have failed.


My web server is (include version): nginx 1.7.10

The operating system my web server runs on is (include version): Ubuntu 20.04 LTS

My hosting provider, if applicable, is:

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 1.4.0.dev0

1 Like

Are you sure there aren’t multiple duplicate server blocks?

Does/do the server block/blocks listen on both IPv4 and IPv6?

What does Nginx’s error.log show?

Can you try removing that location block?

1 Like
  1. Fairly sure. No server blocks in nginx.conf. The other two domain configs:

    server {

     # SSL configuration
     # listen 443 ssl default_server;
     # listen [::]:443 ssl default_server;
     # Note: You should disable gzip for SSL traffic.
     # See:
     # Read up on ssl_ciphers to ensure a secure configuration.
     # See:
     # Self signed certs generated by the ssl-cert package
     # Don't use them in a production server!
     # include snippets/snakeoil.conf;
     root /var/www/rashdanml/;
     autoindex on;
     # Add index.php to the list if you are using PHP
     index index.html index.htm index.php;
     location / {
     	# First attempt to serve request as file, then
     	# as directory, then fall back to displaying a 404.
     	try_files $uri $uri/ =404;
     # pass PHP scripts to FastCGI server
     location ~ \.php$ {
     	include snippets/fastcgi-php.conf;
     #	# With php-fpm (or other unix sockets):
     	fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
     #	# With php-cgi (or other tcp sockets):
     #	fastcgi_pass;
     # deny access to .htaccess files, if Apache's document root
     # concurs with nginx's one
     location ~ /\.ht {
     	deny all;

    listen [::]:443 ssl ipv6only=on; # managed by Certbot
    listen 443 ssl; # managed by Certbot
    ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot
    include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot


    server {
    if ($host = {
    return 301 https://$host$request_uri;
    } # managed by Certbot

    if ($host = {
    return 301 https://$host$request_uri;
    } # managed by Certbot

     listen 80 default_server;
     listen [::]:80 default_server;

    return 404; # managed by Certbot

(The other domain is basically the same except for the root directory and server_name’s, minus the default_server)

  1. See above. It is listening on both.

  2. Last few relevant lines:

2020/05/23 01:32:55 [emerg] 48549#48549: bind() to failed (98: Address already in use)
2020/05/23 01:32:55 [emerg] 48549#48549: bind() to [::]:80 failed (98: Address already in use)
2020/05/23 01:32:55 [emerg] 48549#48549: still could not bind()
2020/05/23 01:33:05 [alert] 48475#48475: unlink() “/run/” failed (2: No such file or directory)
2020/05/23 01:33:20 [notice] 48593#48593: signal process started
2020/05/23 01:33:22 [notice] 48598#48598: signal process started
2020/05/23 01:42:51 [notice] 49024#49024: signal process started
2020/05/23 01:42:53 [notice] 49032#49032: signal process started
2020/05/23 01:43:50 [notice] 49086#49086: signal process started
2020/05/23 01:43:52 [notice] 49091#49091: signal process started
2020/05/23 01:45:29 [notice] 49171#49171: signal process started
2020/05/23 01:45:32 [notice] 49178#49178: signal process started
2020/05/23 02:05:26 [emerg] 49530#49530: duplicate listen options for [::]:443 in /etc/nginx/sites-enabled/rashdanml:71
2020/05/23 02:05:31 [error] 49180#49180: *30 directory index of “/var/www/devrashdanml/” is forbidden, client:, server:, request: “GET / HTTP/1.1”, host: “”
2020/05/23 02:05:46 [error] 49180#49180: *48 directory index of “/var/www/devrashdanml/” is forbidden, client:, server:, request: “GET / HTTP/1.1”, host: “”

Hmm. Issue of permissions, maybe? That’s the only thing that’s jumping out at me. Going to try that and see if it helps.

  1. Removing that location block had the same error (ran the command twice, without the snippet and with).

Note: regarding the duplicate listen options: that was me attempt to copy one of my other domain configs and strip it down without any of the SSL config options to see if that would do anything. It didn’t.


Yup, it was indeed permissions. chown’d to www-data on /var/www/devrashdanml and it worked.

1 Like

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