Can't verify 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. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.

My domain is: guardpost.co.za

I ran this command:
I am following this tutorial: How to Set Up Free SSL Certificates from Let's Encrypt using Docker and Nginx

my docker-compose setup:

version: '3.3'

services:
mongo:
image: mongo
restart: unless-stopped
ports:
- '27017:27017'
volumes:
- data:/data/db
networks:
- app-network
api:
container_name: api
build:
context: ./server
dockerfile: Dockerfile.prod
volumes:
- /app/node_modules
- ./server/:/app
networks:
- app-network
depends_on:
- mongo
env_file: ./server/.env
environment:
- NODE_ENV=production
client:
container_name: client
build:
context: ./client
dockerfile: Dockerfile.prod
environment:
- NODE_ENV=production
volumes:
- ./client/:/app
networks:
- app-network
nginx:
container_name: nginx
restart: unless-stopped
build:
dockerfile: Dockerfile.prod
context: ./nginx
ports:
- '80:80'
volumes:
- ./nginx/production.conf:/etc/nginx/conf.d/default.conf
- ./letsencrypt-site:/usr/share/nginx/html
depends_on:
- api
- client
networks:
- app-network

volumes:
data:
driver: local

networks:
app-network:
driver: bridge

My client container spins up another nginx server and serves my HTML files of port 3000. Nginx listens to this upstream and serves over port 80.

This is working fine, but when I run this command

sudo docker run -it --rm \
-v /docker-volumes/etc/letsencrypt:/etc/letsencrypt \
-v /docker-volumes/var/lib/letsencrypt:/var/lib/letsencrypt \
-v /docker/letsencrypt-docker-nginx/src/letsencrypt/letsencrypt-site:/data/letsencrypt \
-v "/docker-volumes/var/log/letsencrypt:/var/log/letsencrypt" \
certbot/certbot \
certonly --webroot \
--register-unsafely-without-email --agree-tos \
--webroot-path=/data/letsencrypt \
--staging \
-d guardpost.co.za -d www.guardpost.co.za
upstream client {
	server client:3000;
}

upstream api {
	server api:5000;
}

server {
	listen 80;
    server_tokens off;
    server_name guardpost.co.za www.guardpost.co.za;

    location ~ /.well-known/acme-challenge {
        allow all;
        root /usr/share/nginx/html;
    }

    location / {
        proxy_pass http://client;
    }

    location /graphql {
        proxy_pass http://api;
    }
       
}

It produced this output:

Type: unauthorized
Detail: Invalid response from
"\r\n404 Not
Found\r\n<body bgcolor="white">\r\n

404
Not Found

\r\n
"

My web server is (include version):
Nginx

The operating system my web server runs on is (include version):
Ubuntu 20.04.1 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)

I know it's a lot of info. I can access it fine over post 80. I think this is the problem

location ~ /.well-known/acme-challenge {
allow all;
root /usr/share/nginx/html;
}

which nginx server is that gonna check? I think it's checking the one responsible for doing the proxy pass from 3000 to 80, but there are no files there? Maybe I am just to deep into it and super confused.

Please help

2 Likes

Might not line up with:

Just a guess...

2 Likes

Welcome to the Let's Encrypt Community, Sean :slightly_smiling_face:

To start debugging, try using this certbot command:

certbot/certbot \
certonly --webroot \
-w /data/letsencrypt \
-d "guardpost.co.za,www.guardpost.co.za" \
--agree-tos \
--register-unsafely-without-email \
--dry-run \
--debug-challenges \
-vvv

This will cause certbot to create the http-01 challenge files then pause for manual input before continuing with verification. You should be able to see where they're being created at that point. You can visit http://guardpost.co.za/.well-known/acme-challenge/test with a web browser on a device that uses the public internet (i.e. external to your network) then check your nginx access log files to see where the access occurs. Comparing these two pieces of information should give you a start in tracing down your operations. You can use https://www.redirect-checker.org to see what Let's Encrypt sees for any address externally from your network (i.e. from the internet).

2 Likes

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