Sorry, I don''t know where to look.
Show:
cat /root/.acme.sh/wpopken.de/wpopken.de.conf
2 Likes
Sorry for the long delay.
Le_Domain='wpopken.de'
Le_Alt='www.wpopken.de'
Le_Webroot='/www'
Le_PreHook=''
Le_PostHook=''
Le_RenewHook=''
Le_API='https://acme-v02.api.letsencrypt.org/directory'
Le_Keylength='2048'
Le_OrderFinalize='https://acme-v02.api.letsencrypt.org/acme/finalize/113387131/305494631586'
Le_LinkOrder='https://acme-v02.api.letsencrypt.org/acme/order/113387131/282300945117'
Le_LinkCert='https://acme-v02.api.letsencrypt.org/acme/cert/036111e74b7f4e04a51d2aed1fb32410c379'
Le_CertCreateTime='1719527262'
Le_CertCreateTimeStr='2024-06-27T22:27:42Z'
Le_NextRenewTimeStr='2024-08-25T22:27:42Z'
Le_NextRenewTime='1724624862'
I suspect the cause of my troubles is the transition of my DNS-server from server4you.com to cloudflare.com. I started googling with respect to cloudflare and found some hints, but didn't find a solution yet.
Why is that showing "/www"?
2 Likes
Well, /var/www/wpopken.de exists and is well populated, but acme.sh tells me it doesn't exist.
./acme.sh -r -w /var/www/wpopken.de -d wpopken.de
-bash: ./acme.sh: No such file or directory
I realise that acme.sh delivers the error Invalid response from https://wpopken.de/.well-known/acme-challenge/5K92UH6D3RzJazRyZKgL1SdGqgdneKQj8qpmJkf-35g: 404 as a call to https. Should it be not a call to http?
nginx redirects all traffic to http to https, I know that, as it did always, but it looks like cloudflare is doing it as well, and I can't find how to switch this off in cloudflare.
No, bash tells you that acme.sh don't exist.
1 Like
My bad, of course. I'm just inspecting the output of --debug (which could not be caught with tee, surprisingly).
I found the cloudflare switch, but got the same error.
Surprisingly, the very long --debug output to root@VPS-X .acme.sh$ ./acme.sh -r --debug -d wpopken.de | tee -a /tmp/acme-run.log does not contain Le_Webroot at all.
From the --debug output:
´´´
[Mon Sep 16 17:49:10 UTC 2024] Writing token: N7grXVOcqYx8U6O-IeyXuP4ADa3QKX3jKliYqcoziHo to /www/.well-known/acme-challenge/N7grXVOcqYx8U6O-IeyXuP4ADa3QKX3jKliYqcoziHo
[Mon Sep 16 17:49:10 UTC 2024] _currentRoot='/www'
[Mon Sep 16 17:49:10 UTC 2024] wellknown_path='/www/.well-known/acme-challenge'
[Mon Sep 16 17:49:10 UTC 2024] Writing token: N7grXVOcqYx8U6O-IeyXuP4ADa3QKX3jKliYqcoziHo to /www/.well-known/acme-challenge/N7grXVOcqYx8U6O-IeyXuP4ADa3QKX3jKliYqcoziHo
´´´
And indeed there are several entries in this apparently wrong directory:
Mon Sep 16 18:27 root@VPS-X .acme.sh$ ls -latr /www/.well-known/acme-challenge/
total 24
-rw-r--r-- 1 root root 87 Sep 4 16:19 1P4woqqTsypErBD3oWvCdIjUQR-zl6X5bRFxw5thNmc
drwxr-xr-x 3 root root 4096 Sep 4 16:19 ..
-rw-r--r-- 1 root root 87 Sep 4 16:58 51nMNMdM45OMhKmI9_CR3fwMdcjNqAVKTdk3CcceiFE
-rw-r--r-- 1 root root 87 Sep 4 17:18 Ba6rcRveRtV5sMK_W6shyNbKXWxgbFxpLPsi_Km1WGY
-rw-r--r-- 1 root root 87 Sep 16 17:49 N7grXVOcqYx8U6O-IeyXuP4ADa3QKX3jKliYqcoziHo
drwxr-xr-x 2 root root 4096 Sep 16 17:49 .
So I added the switch -w to acme.sh like so:
root@VPS-X ~$ .acme.sh/acme.sh .acme.sh/acme.sh -r -w /var/www/wpopken.de/ -d wpopken.de
But alas to no avail.
For acme.sh the -w path should appear after its domain name
1 Like
Can you just edit that file?
If you can, change:
Le_Webroot='/www'
to:
Le_Webroot='/var/www/wpopken.de'
4 Likes
Just to add to @rg305 comment, your objective is to get
http://wpopken.de/.well-known/acme-challenge/<something> to resolve to the file system location that acme.sh is trying to write http challenge response files to.
So if you had a text file called hello under /var/www/wpopken.de/.well-known/acme-challenge/ then you would be able to request it in your browser with http://wpopken.de/.well-known/acme-challenge/hello
When you think of it as just trying to get your website to serve a file under a specific path (/.well-known/acme-challenge/) it's much simpler to figure out how to achieve that.
3 Likes
I finally solved it. It looks like I used a different path, though. But one after the other:
I just issued ./acme.sh --issue --standalone -d wpopken.de -d www.wpopken.de. It did not work right away, but gave the right hints:.
First I had to install socat:
Thu Sep 19 20:19 root@VPS-X .acme.sh$ ./acme.sh --issue --acme.sh --issue --standalone -d wpopken.de -d www.wpopken.de
[Thu Sep 19 20:21:36 UTC 2024] Using CA: https://acme.zerossl.com/v2/DV90
[Thu Sep 19 20:21:36 UTC 2024] Please install socat tools first.
Next I had to add an email address:
Thu Sep 19 20:23 root@VPS-X .acme.sh$ ./acme.sh --register-account -m ***@gmx.de
[Thu Sep 19 20:23:27 UTC 2024] No EAB credentials found for ZeroSSL, let's obtain them
[Thu Sep 19 20:23:28 UTC 2024] Registering account: https://acme.zerossl.com/v2/DV90
[Thu Sep 19 20:23:29 UTC 2024] Registered
[Thu Sep 19 20:23:29 UTC 2024] ACCOUNT_THUMBPRINT='Cj_B2rc0ynqpGySsIe1BYFLy0L2vmRaju1boztd8N9Q'
Then ./acme.sh --issue --standalone -d wpopken.de -d www.wpopken.de worked like a breeze.
Now I have 2 certificates from 2 different CA, it seems:
root@VPS-X .acme.sh$ ./acme.sh list
Main_Domain KeyLength SAN_Domains CA Created Renew
stuerenburg.com "2048" www.stuerenburg.com LetsEncrypt.org 2024-08-26T00:27:26Z 2024-10-24T00:27:26Z
wpopken.de "2048" www.wpopken.de LetsEncrypt.org 2024-06-27T22:27:42Z 2024-08-25T22:27:42Z
wpopken.de "ec-256" www.wpopken.de ZeroSSL.com 2024-09-19T20:24:09Z 2024-11-17T20:24:09Z
I copied cert and key to
/etc/letsencrypt/live/wpopken.de.acme/fullchain.cer
and
/etc/letsencrypt/live/wpopken.de.acme/wpopken.de.key
and tested with curl -v 'https://wpopken.de' and it worked. Sigh!
I think I can wait for the old CA to expire. Or maybe I revoke it.
I have no idea why acme.sh switched to ZeroSSL.com and what the difference to LetsEncrypt.org is.
Many thanks for everyone helping.
1 Like
See here about setting the CA server: Server · acmesh-official/acme.sh Wiki · GitHub
One difference between LE and ZeroSSL is the kind of support. We don't usually help people using ZeroSSL in this forum, for one. We might but many of us volunteers don't have deep experience with it and this is a Let's Encrypt forum after all.
2 Likes
Thanks for the information. My woes did not stop, unfortunately.
Thu Sep 19 21:37 root@VPS-X .acme.sh$ /root/.acme.sh/acm/root/.acme.sh/acme.sh --cron --home /root/.acme.sh | tee /tmp/acme.log
[Thu Sep 19 21:38:07 UTC 2024] ===Starting cron===
[Thu Sep 19 21:38:07 UTC 2024] Already up to date!
[Thu Sep 19 21:38:07 UTC 2024] Upgrade successful!
[Thu Sep 19 21:38:07 UTC 2024] Automatically upgraded to: 3.0.9
[Thu Sep 19 21:38:07 UTC 2024] Renewing: 'stuerenburg.com'
[Thu Sep 19 21:38:07 UTC 2024] Renewing using Le_API=https://acme-v02.api.letsencrypt.org/directory
[Thu Sep 19 21:38:07 UTC 2024] Skipping. Next renewal time is: 2024-10-24T00:27:26Z
[Thu Sep 19 21:38:07 UTC 2024] Add '--force' to force renewal.
[Thu Sep 19 21:38:07 UTC 2024] Skipped stuerenburg.com
[Thu Sep 19 21:38:07 UTC 2024] Renewing: 'wpopken.de'
[Thu Sep 19 21:38:07 UTC 2024] Renewing using Le_API=https://acme-v02.api.letsencrypt.org/directory
[Thu Sep 19 21:38:08 UTC 2024] Using CA: https://acme-v02.api.letsencrypt.org/directory
[Thu Sep 19 21:38:08 UTC 2024] Multi domain='DNS:wpopken.de,DNS:www.wpopken.de'
[Thu Sep 19 21:38:10 UTC 2024] Error creating new order. Le_OrderFinalize not found. {
"type": "urn:ietf:params:acme:error:rateLimited",
"detail": "Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/failed-validation-limit/",
"status": 429
}
[Thu Sep 19 21:38:10 UTC 2024] Please check log file for more details: /root/.acme.sh/acme.sh.log
[Thu Sep 19 21:38:10 UTC 2024] Error renewing wpopken.de.
[Thu Sep 19 21:38:10 UTC 2024] Renewing: 'wpopken.de'
[Thu Sep 19 21:38:10 UTC 2024] Renewing using Le_API=https://acme.zerossl.com/v2/DV90
[Thu Sep 19 21:38:10 UTC 2024] Skipping. Next renewal time is: 2024-11-17T20:24:09Z
[Thu Sep 19 21:38:10 UTC 2024] Add '--force' to force renewal.
[Thu Sep 19 21:38:10 UTC 2024] Skipped wpopken.de_ecc
[Thu Sep 19 21:38:10 UTC 2024] Sending via: mail
[Thu Sep 19 21:38:10 UTC 2024] mail Success
[Thu Sep 19 21:38:10 UTC 2024] ===End cron===
You did not fix it by correcting the webroot paths though. You instead used a different method. The --standalone method requires exclusive use of port 80 and starts a temp web server to handle the challenge.
Now that you have nginx running on port 80 that standalone method will fail.
You should go back to the prior posts of my fellow volunteers and follow their advice.
Ideally you want to handle the challenge in nginx using webroot path
3 Likes
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.