wmnnd / nginx-certbot

Boilerplate configuration for nginx and certbot with docker-compose

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Keep getting connection refused

devsheva opened this issue · comments

commented

Context:
Trying to setup HTTPS with Nginx, LetsEncrypt and docker compose in an Amazon Linux 2 EC2 Instance

I'm trying to run the init-letsencrypt.sh script to generate certificates for LetsEncrypt.

My docker compose file is this

version: '3'

services:
  # nginx container
  simet-nginx:
    image: nginx:latest
    ports:
      - 80:80
      - 443:443
    restart: unless-stopped
    volumes:
      - ./data/nginx:/etc/nginx/conf.d
      - ./data/certbot/conf:/etc/letsencrypt # save letsencrypt certificates
      - ./data/certbot/www:/var/www/certbot # autorenew HTTPS certs
    command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"
  certbot:
    image: certbot/certbot:arm64v8-latest
    restart: unless-stopped
    volumes:
      - ./data/certbot/conf:/etc/letsencrypt
      - ./data/certbot/www:/var/www/certbot
    entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

I keep getting

 Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
  Domain: example.org
  Type:   connection
  Detail: 34.246.111.238: Fetching http://example.org/.well-known/acme-challenge/GHdklB3122P6phvmC7rcwS2ByeteMgs43MC04WFu05Y: Connection refused

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.

Some challenges have failed.

I met this problem too. Have you solved it?

Same here, anyone has a solution?

It works with .com domain, make sure you replace all example.org in both data/nginx/app.conf and init.letsencrypt.sh , but for example, it doesnt work for the same domain thats on .rs

commented

It works with .com domain, make sure you replace all example.org in both data/nginx/app.conf and init.letsencrypt.sh , but for example, it doesnt work for the same domain thats on .rs

That explains it for me then. I'm using a .au address and get the same issue. Do you know why this occurs?

I was facing the same issue, but it worked for me:

Docker Compose

version: "3"

services:
    certbot:
        image: certbot/certbot
        restart: unless-stopped
        volumes:
            - ./data/certbot/conf:/etc/letsencrypt
            - ./data/certbot/www:/var/www/certbot
        entrypoint: "/bin/sh -c 'trap exit TERM; while :; do certbot renew; sleep 12h & wait $${!}; done;'"

    nginx:
        image: nginx
        volumes:
            - ./data/nginx:/etc/nginx/conf.d
            - ./data/certbot/conf:/etc/letsencrypt
            - ./data/certbot/www:/var/www/certbot
        ports:
            - "80:80"
            - "443:443"
        depends_on:
            - certbot
            - my-backend
        restart: unless-stopped
        command: "/bin/sh -c 'while :; do sleep 6h & wait $${!}; nginx -s reload; done & nginx -g \"daemon off;\"'"

    my-backend:
        image: my-register/my-backend:latest
        ports:
            - "8080:8080"
        restart: unless-stopped

NGINX

server {
    listen 80 default_server;
    server_name my-backend-domain.com.br;
    server_tokens off;

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

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

server {
    listen 443 ssl;
    server_name my-backend-domain.com.br;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/my-backend-domain.com.br/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/my-backend-domain.com.br/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass http://my-backend-domain:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

IMPORTANT: ensure your DNS is pointed to your instance/IP correctly.

commented

So I just solved it as well, but my changes appear to be different to yours.
This was my app.conf file:

NGINX

server {
    listen 80;
    server_name _my-redacted-webaddress.au_;
    server_tokens off;

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

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

server {
    listen 443 ssl;
    server_name _my-redacted-webaddress.au_;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/_my-redacted-webaddress.au_-0001/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/_my-redacted-webaddress.au_-0001/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    location / {
        proxy_pass  http://_my-redacted-webaddres.au_;
        proxy_set_header    Host                $http_host;
        proxy_set_header    X-Real-IP           $remote_addr;
        proxy_set_header    X-Forwarded-For     $proxy_add_x_forwarded_for;
    }
}

Btw, note the directory for the ssl certificates. In the repo and guide, the address doesn't have the 0001 suffix. So it initially didn't work for me. I had a look in the container, and for me this was the folder than that was generated for me. I updated the app.conf to reflect this.

It still wasm't working, and I learnt that the configuration file normally includes a configuration for proxying requests to your backend server. It's my understanding that based on the proxy_pass directive in the HTTPS server block, I was proxying requests to http://my-redacted-webaddress.au, however it appears I should be replacing this with the actual URL of the backend server, which could be running in a separate Docker container.

But in my case, my nginx container is serving the content of my website directly from a local site-content directory, without proxying requests to any backend server. Therefore, I don't need to include the proxy_pass directive in the app.conf file. So I modified the HTTPS server block to serve the content directly from the site-content directory, like this:

NGINX

server {
    listen 443 ssl;
    server_name _my-redacted-webaddress.au;
    server_tokens off;

    ssl_certificate /etc/letsencrypt/live/_my-redacted-webaddress.au_-0001/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/_my-redacted-webaddress.au_-0001/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;

    root /usr/share/nginx/html;
    index index.html;

    location / {
        try_files $uri $uri/ =404;
    }
}

It also meant I could get rid of the lines:

NGINX

proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

Now it's running fine at https://my-redacted-webaddress.au
I'm just learning though so might not be following best practices.

commented

I fixed my concern by switching to Caddy, since i just needed a simple way to setup a reverse proxy with HTTPS handling, and Caddy was perfect since with just two lines of code it does all of that.

However, if you want to know more about my issue, I think I was just pointing to the wrong container IP, cause I wasn't pointing to the docker gateway IP, but to the container IP, which of course is private and you can't access to it.

commented

Wow, that looks really good. I didn't know about Caddy. Cheers!

@devsheva thanks for pointing to Caddy! It is really hassle-free :-)

In my case, There are two reasons it doesn't work for me

  1. I was using docker-compose-staging.yml file in docker compose.
    But in script , it used docker-compose.yml default.

  2. I was adding new domain and then it didn't include ssl_certificate correctly.
    So nginx was not loaded.

After two problem I had solved, it worked well.