It produced this output:Failed authorization procedure. www.external-portal.dyndns.org (http-01): urn:acme:error:connection :: The server could not connect to the client to verify the domain :: DNS problem: NXDOMAIN looking up A for www.external-portal.dyndns.org
To fix these errors, please make sure that your domain name was
entered correctly and the DNS A record(s) for that domain
contain(s) the right IP address. Additionally, please check that
your computer has a publicly routable IP address and that no
firewalls are preventing the server from communicating with the
client. If you’re using the webroot plugin, you should also verify
that you are serving files from the webroot path you provided.
My operating system is (include version): Mac OSX 10.11.6 El Capitan
My web server is (include version):Mac OSX 10.11.6 El Capitan
My hosting provider, if applicable, is: This is a MacMini on my LAN
I can login to a root shell on my machine (yes or no, or I don’t know): I think so, yes
I’m using a control panel to manage my site (no, or provide the name and version of the control panel):NO
I am using DYNDNS to point to my IP address. The MacMini I am using as a webserver is inside the LAN and I have a Draytek Router redirecting port 80 and 443 to my internal ip address. I have tried setting the MacMini inside a DMZ (temporarily as a troubleshooting idea) but I still cannot connect.
As I am by no means an expert in this area I would really appreciate some help here. I am trying to serve a Filemaker Database to fellow colleagues externally. The database was accessible under http: but I would like to have the dataflow encrypted for security reasons. Thinking that it could be the Filemaker Server that was causing the problem, I uninstalled it and started from scratch with a newly formatted HDD. So now I have nothing on the MacMini except the OS, Xcode and command line tools, Homebrew and the LetsEncrypt software.
Really I would appreciate some help getting the certificates issued so I can move on an install Filemaker again.
It may even be a coincidence that the Apache server wasn’t running; the DNS issue related to www.external-portal would be enough to produce this error message all by itself, while that issue would go away if you ran Certbot without the second -d.