OK, now it can be reached:
curl -Iik http://45.76.43.163
HTTP/1.1 200 OK
Date: Tue, 14 Mar 2023 18:07:28 GMT
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Tue, 14 Mar 2023 14:52:26 GMT
ETag: "2aa6-5f6dd603fc82e"
Accept-Ranges: bytes
Content-Length: 10918
Vary: Accept-Encoding
Content-Type: text/html
Now you can try and get a cert using apache
OR
Turn apache off and use acme.sh in standalone mode.
Well, I can't because apache2 uses port... And if I uninstall apache2 - will get to the previous state. The more I'm thinking - the more it looks like some extra-evil firewall on host (which hosts my vps) filters out acme traffic or something
yeah... after uninstalling apache and re-running acme got it the same situation 
What shows?:
ufw status
Did not mean:
It meant: "stop" apache
ah, okay, trying this.
also: ufw status
Status: active
To Action From
8080:8083/tcp ALLOW Anywhere
22/tcp ALLOW Anywhere
3919/tcp ALLOW Anywhere
3920/tcp ALLOW Anywhere
9151/tcp ALLOW Anywhere
1080 ALLOW Anywhere
1443 ALLOW Anywhere
80 ALLOW Anywhere
443 ALLOW Anywhere
8080:8083/tcp (v6) ALLOW Anywhere (v6)
22/tcp (v6) ALLOW Anywhere (v6)
3919/tcp (v6) ALLOW Anywhere (v6)
3920/tcp (v6) ALLOW Anywhere (v6)
9151/tcp (v6) ALLOW Anywhere (v6)
1080 (v6) ALLOW Anywhere (v6)
1443 (v6) ALLOW Anywhere (v6)
80 (v6) ALLOW Anywhere (v6)
443 (v6) ALLOW Anywhere (v6)
same issue after
sudo /etc/init.d/apache2 stop
Stopping apache2 (via systemctl): apache2.service.
That looks OK:
What was the full command used?
What was the error message?
Does that also produce any type of log file?
full command:
acme.sh --issue --standalone -d eldernode2.ddns.net --force --debug 2
error message (if executed without --debug 2):
acme.sh --issue --standalone -d eldernode2.ddns.net --force
[Tue 14 Mar 2023 06:49:29 PM UTC] Using CA: https://acme.zerossl.com/v2/DV90
[Tue 14 Mar 2023 06:49:29 PM UTC] Standalone mode.
[Tue 14 Mar 2023 06:49:29 PM UTC] Single domain='eldernode2.ddns.net'
[Tue 14 Mar 2023 06:49:30 PM UTC] Getting domain auth token for each domain
[Tue 14 Mar 2023 06:49:30 PM UTC] Getting webroot for domain='eldernode2.ddns.net'
[Tue 14 Mar 2023 06:49:31 PM UTC] Verifying: eldernode2.ddns.net
[Tue 14 Mar 2023 06:49:31 PM UTC] Standalone mode server
[Tue 14 Mar 2023 06:49:32 PM UTC] Processing, The CA is processing your order, please just wait. (1/30)
[Tue 14 Mar 2023 06:49:35 PM UTC] eldernode2.ddns.net:Verify error:"error":{
[Tue 14 Mar 2023 06:49:35 PM UTC] Please check log file for more details: /root/.acme.sh/acme.sh.log
tail -f /root/.acme.sh/acme.sh.log
[Tue 14 Mar 2023 06:49:35 PM UTC] skip dns.
[Tue 14 Mar 2023 06:49:35 PM UTC] _on_issue_err
[Tue 14 Mar 2023 06:49:35 PM UTC] Please check log file for more details: /root/.acme.sh/acme.sh.log
[Tue 14 Mar 2023 06:49:35 PM UTC] url='https://acme.zerossl.com/v2/DV90/chall/dVVQ9ZkaZOiRkC78Yr5DOw'
[Tue 14 Mar 2023 06:49:35 PM UTC] payload='{}'
[Tue 14 Mar 2023 06:49:35 PM UTC] POST
[Tue 14 Mar 2023 06:49:35 PM UTC] _post_url='https://acme.zerossl.com/v2/DV90/chall/dVVQ9ZkaZOiRkC78Yr5DOw'
[Tue 14 Mar 2023 06:49:35 PM UTC] _CURL='curl --silent --dump-header /root/.acme.sh/http.header -L -g '
[Tue 14 Mar 2023 06:49:35 PM UTC] _ret='0'
[Tue 14 Mar 2023 06:49:35 PM UTC] code='200'
**https://acme.zerossl.com/v2/DV90/chall/dVVQ9ZkaZOiRkC78Yr5DOw**:
{"type":"urn:ietf:params:acme:error:malformed","status":405,"detail":"The request message was malformed"}
ha, just tried with '--server letsencrypt' and it did produce something!
Are you still using this option even though you were warned against it? Please note that --force does not *MAGICALLY make previous errors go away, but can lead to hitting rate limits (in the case of Let's Encrypt) and increase the load on the systems for no good reason.
Please don't use it any more.
got it, okay
This file may show us more/why things are failing.
And, yes; Stop using the --force!
I've pasted content of this file in previous reply:
tail -f /root/.acme.sh/acme.sh.log
[Tue 14 Mar 2023 06:49:35 PM UTC] skip dns.
[Tue 14 Mar 2023 06:49:35 PM UTC] _on_issue_err
[Tue 14 Mar 2023 06:49:35 PM UTC] Please check log file for more details: /root/.acme.sh/acme.sh.log
[Tue 14 Mar 2023 06:49:35 PM UTC] url='https://acme.zerossl.com/v2/DV90/chall/dVVQ9ZkaZOiRkC78Yr5DOw'
[Tue 14 Mar 2023 06:49:35 PM UTC] payload='{}'
[Tue 14 Mar 2023 06:49:35 PM UTC] POST
[Tue 14 Mar 2023 06:49:35 PM UTC] _post_url='https://acme.zerossl.com/v2/DV90/chall/dVVQ9ZkaZOiRkC78Yr5DOw'
[Tue 14 Mar 2023 06:49:35 PM UTC] _CURL='curl --silent --dump-header /root/.acme.sh/http.header -L -g '
[Tue 14 Mar 2023 06:49:35 PM UTC] _ret='0'
[Tue 14 Mar 2023 06:49:35 PM UTC] code='200'
... and following the link results in this:
{"type":"urn:ietf:params:acme:error:malformed","status":405,"detail":"The request message was malformed"}
anyway, huge thanks to everybody, I've got the issue resolved and certs generated by using the following cmd:
acme.sh --issue --server letsencrypt --standalone -d eldernode2.ddns.net
Glad to hear that [LE saved the day]!
LE worked where ZeroSSL could not:
Not sure why that can happen...
What version of acme.sh is that?
Is that the error when using ZeroSSL but not setting up any EAB?
acme version is 3.0.6
just to clarify, I've used absolutely the same line from different vps a few month ago and it used to work at that time. At least I don't recall any EAB or something... So the only change was in vps itself. My new theory - ZeroSSL is probably geofencing (or vultr filtering ZeroSSL)
The 405 error seems like it's from the ZeroSSL side of the fence.
If it's a new VPS then maybe it has a new account which has not yet had EAB setup
I'm just guessing. I don't do ZeroSSL support 