Certbot failed to authenticate

Hi

I'm learning how to build a website using docker and I need to secure it.

I'm following this tutorial as a guide,
Develop and Deploy Laravel Applications with Docker..

I've tried running

docker-compose -f docker-compose.prod.yml run --rm certbot -v certonly -d pactest.tk

with two different nginx config files as its not entirely clear if it needs to be run before ssl is added.

There is no log file or or folder in var/log called letsencrypt.log

Any help debugging would be great?

1 nginx.prod.conf

server {
    listen 80;
    index index.php index.php;
    server_name pactest.tk;
    root /var/www/html/public;
    client_max_body_size 100M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }
}

2 ssl attempt nginx.prod.conf

server {
    listen 80 default_server;

    server_name _;

    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    index index.php index.html;
    server_name pactest.tk;
    root /var/www/html/public;
    client_max_body_size 100M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }

    location /.well-known/acme-challenge/ {
        root /var/www/certbot;
    }

    location ~ \.php$ {
        try_files $uri =404;
        fastcgi_split_path_info ^(.+\.php)(/.+)$;
        fastcgi_pass php:9000;
        fastcgi_index index.php;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_param PATH_INFO $fastcgi_path_info;
    }

    ssl_certificate /etc/letsencrypt/live/pactest.tk/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/pactest.tk/privkey.pem;
}

docker yml file

version: '3.8'


networks:
  laravel:
    name: laravel

services:
  nginx:
    build:
      context: .
      dockerfile: nginx.dockerfile
    container_name: nginx
    depends_on:
      - php
      - mysql
    ports:
      - 80:80
      - 443:443
      - 8080:8080
    volumes:
      - ./src:/var/www/html
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    networks:
      - laravel

  php:
    build:
      context: .
      dockerfile: php.dockerfile
    container_name: php
    volumes:
      - ./src:/var/www/html
    networks:
      - laravel


  mysql:
    image: mysql:5.7.32
    container_name: mysql
    volumes:
      - ./mysql:/var/lib/mysql
    ports:
      - 4306:3306
    environment:
      MYSQL_DATABASE: pac_web_site
      MYSQL_PASSWORD: PacWebSite
      MYSQL_ROOT_PASSWORD: PacWebSite
    networks:
      - laravel

  composer:
    image: composer:latest
    container_name: composer
    volumes:
      - ./src:/var/www/html
    working_dir: /var/www/html
    networks:
      - laravel

  artisan:
    build:
      context: .
      dockerfile: php.dockerfile
    container_name: artisan
    volumes:
      - ./src:/var/www/html
    working_dir: /var/www/html
    entrypoint: ["php", "artisan"]
    networks:
      - laravel

  npm:
#    image: node:13.7
    image: node:14.17.6
    container_name: npm
    volumes:
      - ./src:/var/www/html
    working_dir: /var/www/html
    entrypoint: ["npm"]
    ports:
      - 3000:3000
      - 3001:3001
    networks:
      - laravel

  certbot:
    image: certbot/certbot
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot

My domain is:
pactest.tk

I ran this command:
docker-compose -f docker-compose.prod.yml run --rm certbot -v certonly -d pactest.tk

It produced this output:

Requesting a certificate for pactest.tk
Performing the following challenges:
http-01 challenge for pactest.tk
Input the webroot for pactest.tk: (Enter 'c' to cancel): /var/www/certbot
Waiting for verification...
Challenge failed for domain pactest.tk
http-01 challenge for pactest.tk

Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:  Domain: pactest.tk
  Type:   unauthorized
  Detail: Invalid response from http://pactest.tk/.well-known/acme-challenge/tCzf8p8VjaP1gMTh6lYl-vwVPXNLfjptlHGICi2px1g [68.183.42.111]: "<!doctype html>\n<html lang=\"en\">\n    <head>\n        <title>Page Not Found</title>\n\n        <meta charset=\"utf-8\">\n        <meta "

Hint: The Certificate Authority failed to download the temporary challenge files created by Certbot. Ensure that the listed domains serve their content from the provided --webroot-path/-w and that files created there can be downloaded from the internet.

Cleaning up challenges

My web server is (include version):
nginx:stable-alpine

The operating system my web server runs on is (include version):
nginx:stable-alpine

My hosting provider, if applicable, is:
digital ocean

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

Blockquote

Hi @pandarhys welcome to the LE community forum :slight_smile:

You will need a functional HTTP site before you can secure it (via HTTP authentication).

Unfortunately, at the moment, it seems that the root servers for .tk are having trouble.
[at least from my point on the Internet]

All are failing to respond:
nslookup -q=ns pactest.tk a.ns.tk
nslookup -q=ns pactest.tk b.ns.tk
nslookup -q=ns pactest.tk c.ns.tk
nslookup -q=ns pactest.tk d.ns.tk

curl -Iki pactest.tk
curl: (6) Could not resolve host: pactest.tk

update: it seems their issue is strictly with IPv4 IPs.
update2: DNS Spy report for pactest.tk


["Digital Ocean DNS" (via CloudFlare)]]

Hi rg

Thank you for the response.

I'm using a free .tk domain name, do you think paying for one would resolve this issue?

Or is there more I have to do within the server configuration in regards to http authentication?

1 Like

Not really; The problem is likely transient - like the Facebook/Twitter/WhatsApp outage yesterday.
This could, perceivably, happen to any TLD.

That step has yet to be taken - maybe yes, maybe no.

Seems to be working today.

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