Still untangling issues with a centos 8 server I build. I've dealt with a lot of it but I have discovered why LE cant issue the cert - it cant validate the domain! from server.sh log: 16.01.2022-17:14 - DEBUG - safe_exec cmd: xfs_quota -x -c 'timer -bir -i 604800' '/' - return code: 1 16.01.2022-17:14 - DEBUG - safe_exec cmd: chattr +i '/var/www/clients/client0/web2' - return code: 0 which: no acme.sh in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin) which: no acme.sh in (/usr/local/ispconfig/server/scripts) 16.01.2022-17:15 - WARNING - Could not verify domain olsheskydesign.com, so excluding it from letsencrypt request. 16.01.2022-17:14 - DEBUG - safe_exec cmd: xfs_quota -x -c 'timer -bir -i 604800' '/' - return code: 1 16.01.2022-17:14 - DEBUG - safe_exec cmd: chattr +i '/var/www/clients/client0/web2' - return code: 0 which: no acme.sh in (/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin) which: no acme.sh in (/usr/local/ispconfig/server/scripts) 16.01.2022-17:15 - WARNING - Could not verify domain olsheskydesign.com, so excluding it from letsencrypt request. now olsheskydesign.com is a website on this server (and after all I ticked the SSL boxes under it). but I notice: from the server: ping olsheskydesign.com does NOT produce ping returns! ping 127.0.0.1 works fine. ifconfig shows lo is UP and running. I'm assuming since I cant ping the website on this server FROM this server thats why LE fails! any thoughts??
read it done that the debug output is above. obviously acme cant validate the domain since its not reponding to pings!
What is the output of Code: dig A olsheskydesign.com on that server? Have you just created the A record for that domain?
[root@ns2 etc]# dig A olsheskydesign.com ; <<>> DiG 9.11.20-RedHat-9.11.20-5.el8_3.1 <<>> A olsheskydesign.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34672 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;olsheskydesign.com. IN A ;; ANSWER SECTION: olsheskydesign.com. 1554 IN A 70.163.30.240 ;; Query time: 10 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Sun Jan 16 17:48:32 EST 2022 ;; MSG SIZE rcvd: 63 [root@ns2 etc]# now I DID stupidly have the hostname mistped in /etc/hosts but fixed that. and restart network. I can ping ns2.odesigngroup.com (this server).: [root@ns2 etc]# ping ns2.odesigngroup.com PING ns2.odesigngroup.com (192.168.2.15) 56(84) bytes of data. 64 bytes from ns2.odesigngroup.com (192.168.2.15): icmp_seq=1 ttl=64 time=0.031 ms 64 bytes from ns2.odesigngroup.com (192.168.2.15): icmp_seq=2 ttl=64 time=0.033 ms 64 bytes from ns2.odesigngroup.com (192.168.2.15): icmp_seq=3 ttl=64 time=0.023 ms ^C --- ns2.odesigngroup.com ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 80ms rtt min/avg/max/mdev = 0.023/0.029/0.033/0.004 ms [root@ns2 etc]# ping olsheskydesign.com PING olsheskydesign.com (70.163.30.240) 56(84) bytes of data. ^C --- olsheskydesign.com ping statistics --- 3 packets transmitted, 0 received, 100% packet loss, time 81ms [root@ns2 etc]# ping www.olsheskydesign.com PING www.olsheskydesign.com (70.163.30.240) 56(84) bytes of data. ^C --- www.olsheskydesign.com ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 158ms how odd. but again, it LE cant verify the domain. I'm believing this is why!
serverhostname is ns2.odesigngroup.com. fumblefingers put in ns2.olsheskydesign.com instead. I did restart networking.
One note to this, I have seen relatable issues that went away after X hrs due to propagation. Disabling the check worked but in the long term it's better to have it enabled.
Yes, the check should be kept enabled whenever possible as it prevents other LE issues like including nonexistent subdomains into the LE cert which will cause it to fail too.
and yes I'm pretty sure if WOULD work - but also within customer's house SHE cant get on HER website. thats likely to be a problem! I can reach her server (obviously) and I can ping the website from outside her local network. but not inside! got to be something simple. then if her website responds, LE will work as well I'm sure! but what the heck??! I did do a workaround. heck. put the website and www.thewebsite IN the /etc/hosts. now pings properly and LE issues. but I'm still wondering
Then the reason for the issue can be the router that is used in that network, the issue is very likely not ISPConfig related or related to the server then, that's why we mention in the LE FAQ. Many routers block access when you try to access a site from inside as the network as the Ip that the client inside the network gets as result of the DNS request is the external IP of the router and the router then blocks such requests. If its just a single PC or a few PC's in that network that shall be able to access that website, then disable LE check in ISPConfig as I mentioned to be able to get an LE cert and then edit the hosts files of the clients that shall be able to access that site and add lines for the domain name of that site with the internal IP. It might also be that the router offers a similar capability to define such internal records which get prioritized over external resolve requests.
its a standard cheap cox network router and I had it setup properly as far as I can tell (all port forwarding works).. but I guess this will 'fix' it. as long as no other consequences! of course, I will have to add this to the windows computers lmhosts on her network! what a pain! thanks
Some of them, especially the cheaper customer routers, simply block such traffic by default. So it is indeed likely that there was no mistake in setting it up and that there is no option to change it, we can just work around it
agreed. but I've set up hundreds and hundreds of these and never run into the cant ping internally issue (except stupid DNS problems and the DNS servers are NOT in her house!) might want to ad a line to the LE FAQ - 'if you cant ping the website, you wont get a cert'. might help others thats what the DEBUG script told me and easy to check before that step!
We already do that: "If one of these domains and subdomains is unreachable (no DNS, wrong DNS, closed firewall, etc)" "Check that all domain names (incl. auto subdomain www etc), subdomains and aliasdomains really point to the right website and are working. Open one after another in your browser and test that." And if none of those basic steps work (I can see you miss this as it only occurs on local network), then we point to run the server.sh script in debug mode and you'll find it.
I was just thinking add the Ping test. its so simple. If you cant ping it no LE cert for YOU! and do it FROM the server. your text above FAILED in my case - I COULD open a browser and pull up the website properly - just NOT FROM HER SERVER! so I thought I had passed this step when I had infact not! make sure you can ping the site FROM the ISPconfig server would add a useful bit of information.
Let's encrypt does not use ping, it needs http; successfully pinging the website name does not mean that http will work, not does a ping failure mean that http will fail. Checking http is the correct test
true but ping fails do indicate a problem (and here it also killed LE). that might be a useful addition. easier than checking http from an ssh session.
That is not always the case, it depends on your setup, eg. if ping is blocked in a firewall it will always fail and that would actually indicate that the firewall is working correctly, not that a web server is inaccessible. No, nothing involved in issuing letsencrypt certificates uses ping, ISPConfig's check uses http, as do the letsencrypt servers, the thing that got thrown off was your troubleshooting steps, where using ping would have helped you identify the issue sooner. But that's not always the case, and I don't know that adding a note along the lines of, "if you can't ping your website from your web server, that often indicates a problem" would in general be helpful or confusing. The follow-up explanation required to describe when ping may or may not be expected to fail, how to identify a public vs private addr, and how to proceed in various cases is likely to be much less useful than the current instruction to simply "Skip letsencrypt check" when the server is behind NAT, and to test all possible site names in a browser. (Admittedly, that "test from a browser" instruction might do with saying to test from another point on the internet, not from the same network as the server.) It's not that very different. Code: ping: ping www.whatever.tld vs. http: wget www.whatever.tld
