Cant renew certificate

[mrchip]

My domain is: sys10.crabdance.com

I ran this command: Running a docker compose which creates 4 containers: nextcloud, jrcs/letsencrypt-nginx-proxy-companion, jwilder/nginx-proxy:alpine, mariadb

It produced this output: Everything was fine until june 6th and it looks like it wont do a cert renewal. When I go to the url the browser blocks it with NET::ERR_CERT_AUTHORITY_INVALID.

The letsencrypt portion of the docker-compose.yml has this:

---

letsencrypt:
image: jrcs/letsencrypt-nginx-proxy-companion
container_name: yourfile-letsencrypt
depends_on:
- proxy
networks:
- network
volumes:
- ./proxy/certs:/etc/nginx/certs:rw
- ./proxy/vhost.d:/etc/nginx/vhost.d:rw
- ./proxy/html:/usr/share/nginx/html:rw
- /etc/localtime:/etc/localtime:ro

---

I then ran "docker exec -ti jrcs/letsencrypt-nginx-proxy-companion bash" to enter into the container and run the start.sh (cant tell you what's in it as "nano" is not found in that container nor is "Apt" to install nano).
start.sh started running until it reached "Verifying: sys10.crabdance.com. it reported "Pending" 4 times then "sys10.crabdance.com:Verify error:65.110.xxx.xxx; Fetching http://sys10.crabdance.com/.well-known/acme-challenge/; Timeout during connect (likely firewall problem)
Please check log file for more details; /dev/null"

I would check that but not sure if that is referring to the letsencrypt container or the main nextcloud folder where docker compose is run from. If it's in the container I cant get nano to work and any other files found in /dev/null

If this helps - in my config.php I have a "trusted_domains" with an array listing both a local computer (192.168.x.x) and the sys10.crabdance.com.
My firewall has both http and https pointing to the correct ip where the service is running. It was also running properly before June 4th or 6th

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): Using Debian - terminal

The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot): command not found

Not sure what other info you will need or where/what container to find it in and or how to read it if nano is not running within the container.
Thanks

[orangepizza]

https://hub.docker.com/r/jrcs/letsencrypt-nginx-proxy-companion/

jrcs/letsencrypt-nginx-proxy-companion is a legacy registry.

Please switch to the new registry of this project for up to date documentation and images: nginxproxy/acme-companion.

but I think you'd better using caddy instead of those two nginx container unless you need specific reqirements. most time container editing other containers setup are brittle.

[MikeMcQ]

I can't parse through all those "moving parts" but maybe this helps

This error:

@mrchip

Verify error:65.110.xxx.xxx; Fetching http://sys10.crabdance.com/.well-known/acme-challenge/; Timeout during connect (likely firewall problem)

Is because that domain cannot be reached using HTTP (port 80). The Let's Encrypt servers need that to work to satisfy the HTTP Challenge and prove your control of the domain name. I can see your domain fine with HTTPS (port 443) apart from the bad cert it uses. But, it looks like you have some sort of firewall or routing problem with port 80.

The Let's Debug test site is helpful when debugging these kinds of problems (https://letsdebug.net)

In case you don't know why you get the cert error ... Use a site like below to see details of the cert. Spoiler: It's a self-signed cert letsencrypt-nginx-proxy-companion

SSL Checker

[mrchip]

Thanks...I'll dig into caddy

[mrchip]

Thanks I got it to work. It was in the firewall. I had been following a tutorial on firewalls (separate issue/learning) and it said to reroute everything from port 80 to 443. When I had this problem I read that letsencrypt needed to talk on 80 so I had removed the port 80 - 443 redirect rule but forgot to portforward 80 to the letsencrypt server. Thanks for the url to check so I could test @MikeMcQ and the reminder about port 80 needing to resolve. I'm also glad to hear you couldn't parse through all the moving parts as I too thought it was crazy to have it set up like that but was following the online tutorial & it worked.
Also,I will be checking into how to update that nginxproxy/acme-companion or use caddy @orangepizza