Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for id34s.duckdns.org
Certbot failed to authenticate some domains (authenticator: standalone). The Certificate Authority reported these problems:
Domain: id34s.duckdns.org
Type: unauthorized
Detail: 81.152.225.107: Invalid response from https://id34s.duckdns.org/.well-known/acme-challenge/XqRlZfSqj7s4IxMRkgtenfU2uee5avczaooXz1co09s: 400
Hint: The Certificate Authority failed to download the challenge files from the temporary standalone webserver started by Certbot on port 80. Ensure that the listed domains point to this machine and that it can accept inbound connections from the internet.
Some challenges have failed.
Ask for help or search for solutions at https://community.letsencrypt.org. See the logfile /var/log/letsencrypt/letsencrypt.log or re-run Certbot with -v for more details.
My web server is (include version):
apache2 is already the newest version (2.4.57-2).
The operating system my web server runs on is (include version):
Debian GNU/niux trixie/sid
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):
Most likely as I connect to the internet through a router
I have another HW (raspberry pi) that is connected to the internet and has router's port 80 forwarded to the Rpi port 80.
Might this be the issue?
Any specific thing to look out for?
Ok,
now,
I have a docker container/image named memos - on the LAN at 192.168.1.118 - I mapped it to port 5230
so when I try to access the service from my mobile phone using my domainname.duckdns.org:5230
I can reach the service
But its http which to my understanding if someone evesdrop on the communication they can know the credentials.
How do I use certbot to make it be https? to avoid the evesdropping?
because you can only point your router's port 80 to a single machine. This way you still point port 80 to a single machine, that handles TLS for every service, but knows which of your local machines to forward requests to.
This is pretty much a limitation of only having a single IP address, if you have (and want to use) IPv6, each machine gets its own publicly addressable IP and no port forwarding is necessary. (If your firewall agrees)
People REALLY should stop using ChatGPT for stuff they don't understand. ChatGPT is a language model, it's (fortunately or unfortunately, you choose) NOT some very intelligent AI. They advertise as such and as a language model it can generate fine pieces of text, but deep down it's DUMB AS (#)*$).
The problem is: you don't know the answer is incorrect or plain stupid if you don't have some knowledge of the subject at hand. Therefore one must NOT use ChatGPT for substantial questions if one does not have at least the basic of knowledge. Or one must verify every detail of the answer first.
so its best to put the reverse proxy on a machine that is always on - like the Rpi ?
If I use IPv6 of a device (or the docker container that has the service I want to expose to the web) and map the domain name to that ipv6 number I don't need port forwarding?
Yes, I do know that it is just a machine.
But for someone like me - who is a weekend tinkerer - who has no one to ask, chatGPT has its uses.
Worse case if it does not work - I can come to a forum and show that I have done some work - then when people offer help, which is always very generous of them, I am learning from their help.
yes, if the machine running the reverse proxy goes down, everything goes down. (it becomes inaccessible, at least)
no, because you won't be using the ip of your router. You will be using the public IPv6 of the actual device. The router firewall might complain, but there's no port forwarding there.
means that no I don't need port forwarding because the device has its own public IPv6 ?
Does it mean that every device that has IPv6 is naturally public facing?
There can be all the middlemen you want, each with their own firewall, but there will be no NAT to hide behind (which is not a safety measure, it's mostly a nuisance).
OK,
Last question and I promise to say bye bye
The docker container itself does not have IPv6 because it is a container hosted on a machine using the machine's network card
The machine has ipv6 but if I have few docker containers how can the request be sent to the specific docker container?
Yes, that depends on how you expose the service on that machine.
Also, it's not strictly true that the container doesn't have an IPv6. But with containers there's not yet a good consensus on how IPv6 should be used. Enable IPv6 support | Docker Documentation
Docker was build around IPv4 and nat, so it's not clear if containers should get IPv6 addresses from a private subnet, or from a public subnet (in which case, the whole concept of "exposing a port" goes out of the window)
