idontknow 0 Posted September 9, 2021 (edited) I hope someone can help: I am trying since hours to get the "OverbyteIcsX509CertsTst" example (from 01.09.2021, ICS 8.67) work on a customers pc. On my own pc it works fine, same exe. Here's what i've done in both cases : I created a new DYNDNS-Host. I set up the Dyndns-Account in the router, i checked it's working. I set up a Port-Forwarding from external port 443 to internal port 443 to the local ip address of the pc. I created some empty folders on hdd "d:\testlets\log", "d:\testlets\account", "d:\testlets\wellknown", "d:\testlets\public". Then i started the OverbyteIcsX509CertsTst.exe which i have compiled with Delphi 10.4 Version 27.0.40680.4203. I typed in the foldernames in the corresponding edits, checked "TLS-ALPN - Local Web", Private Key File Encryption AES 256, type in the complete dyndns-url, clicked on "Test Domain Challenges", which ran fine in both cases. I choose the "https://acme-v02.api.letsencrypt.org/directory" server, selected "RSA 4096..." and checked over and over again, that the settings on my pc are the same as they are on the customers one. On both sides i have comparable results, but if it comes to step "Start Challenges (5)", then the customers pc seems to get no answer after "ACME certificate order placed, automatic collection enabled". Here is a snippet from the customers logfile: 09.09.21, 17:51:47.889 [info] [20300] [main] Challenge requested for: myletsencrypttest4.dyndns.org 09.09.21, 17:51:47.891 [info] [20300] [main] ACME certificate order placed, automatic collection enabled 09.09.21, 17:52:02.612 [info] [20300] [main] 17:52:02 Challenge Done Check 09.09.21, 17:52:02.612 [info] [20300] [main] 2021-09-09T17:52:02 09.09.21, 17:52:02.612 [info] [20300] [main] Checking Acme Challenge for: myletsencrypttest4.dyndns.org 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST POST https://acme-v02.api.letsencrypt.org/acme/chall-v3/29433226520/u4mf2w {"protected":"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2FjY3QvMTk0MTk3NzYwIiwibm9uY2UiOiIwMTAxVjczNFRMN1lGaGxSNUl5eld0Qm9mM2ltYlpCYVdQSkxJaDg5VVNMZHg2NCIsInVybCI6Imh0dHBzOi8vYWNtZS12MDIuYXBpLmxldHNlbmNyeXB0Lm9yZy9hY21lL2NoYWxsLXYzLzI5NDMzMjI2NTIwL3U0bWYydyJ9","payload":"","signature":"C-Ya0PKvc4sZtGVBX2c3rQNRMMcINOIXpTmgURg7A_zqKVYDrnBJt5IOLigtZqYMbSbsfWIvvGzruA6SZo9DcPKxlmI1YolOH6zn0sn0924yolk0UoYQwOJWQ-Pc4sTrIiBS0o11KknMZb3IEOr6flQ413UgSNVUnunE9WtJzpLXAo4elEqXFWJThqjdlhsEuVRNYIOWpxJqeBzYLUXVuxdKg1HGGxKWlYhuUhU5DqINquKDX_qgKmw4Lhxqrnd3eTmnRw_1wg4SobQ777K3of2fYnVV4xoRsdp3qUaDoElkQHZa3clO0uGJDRM6A9qQADXaFTJ_cBZbSYxNqg-8hEoB8wMSXK5TcLJkaGV2nanE8TUeVCpFqzJD9R3EER29vM6nFVzrz-T-35mqjEbB1XIIjgw2XjRIvsoDFIEQd3c0x06zezEVdFDXZF_1IvCGwGOG-nuQnN-ckLw2FHD0VK8wJ30PJ-X2KKteosQzbSpCC_rOLBthAE7VO3v9DRr97sxAhaWYPbiEwO7FcXDT8T6m5Rl_oq_H-u-udlRAHlEUBtVCrEcQuqHwYAlcuesvJwiLT83PIEkGJChgab05NHit_nMSt4aTvet3YrLO7raKXuQxfn3JoDM5XlvqiKitJ1eC_dOPAeJUoon1MdRpsD16a44Djs34FDQK2Eu-Bck"} 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST Connected OK to: acme-v02.api.letsencrypt.org (172.65.32.248) 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > POST /acme/chall-v3/29433226520/u4mf2w HTTP/1.1 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > Accept: */* 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > Accept-Encoding: gzip, deflate 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > Content-Type: application/jose+json 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > User-Agent: ICS-ACME-V8.67 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > Host: acme-v02.api.letsencrypt.org 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > Content-Length: 1015 09.09.21, 17:52:02.684 [info] [20300] [main] HTTP REST > 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < HTTP/1.1 200 OK 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Server: nginx 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Date: Thu, 09 Sep 2021 15:52:02 GMT 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Content-Type: application/json 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Content-Length: 640 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Connection: keep-alive 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Boulder-Requester: 194197760 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Cache-Control: public, max-age=0, no-cache 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index" 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Link: <https://acme-v02.api.letsencrypt.org/acme/authz-v3/29433226520>;rel="up" 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Location: https://acme-v02.api.letsencrypt.org/acme/chall-v3/29433226520/u4mf2w 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Replay-Nonce: 0102Edm55tArxI7QZLMQ40DeD2SvLe7DVBbbPA7wvh1WGVU 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < X-Frame-Options: DENY 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST < Strict-Transport-Security: max-age=604800 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST Request completed: 200 OK 09.09.21, 17:52:02.891 [info] [20300] [main] HTTP REST Response (length 640) { "type": "tls-alpn-01", "status": "invalid", "error": { "type": "urn:ietf:params:acme:error:connection", "detail": "Error getting validation data", "status": 400 }, "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/29433226520/u4mf2w", "token": "Yuce1-oKueEpV8POY0bgxRFkxiQXcv3qXGGL9mA2J6A", "validationRecord": [ { "hostname": "myletsencrypttest4.dyndns.org", "port": "443", "addressesResolved": [ "91.53.90.77", "2003:e3:efff:1972:de39:6fff:fe45:4515" ], "addressUsed": "2003:e3:efff:1972:de39:6fff:fe45:4515" } ], "validated": "2021-09-09T15:51:47Z" } 09.09.21, 17:52:02.891 [info] [20300] [main] Acme challenge Failed: Error getting validation data for: myletsencrypttest4.dyndns.org 09.09.21, 17:52:02.891 [info] [20300] [main] Cleaning up old challenge for: myletsencrypttest4.dyndns.org Does anybody know whats going wrong there? Some more informations: The customer has the same router as i have, a FritzBox 7590 with FritzOS 7.28. He has a real IPv4 address, as i have. Customer: Telekom. Windows 10 Firewall is disabled. Speedtest-Sites are showing the same external ipv4 address as the router, so it seems to be a real ipv4 address, not a carrier grade nat one... Edited September 9, 2021 by idontknow Share this post Link to post
Angus Robertson 574 Posted September 9, 2021 The error is that your local web server can not be accessed at 2003:e3:efff:1972:de39:6fff:fe45:4515, did you setup port forwarding for that IPv6 address and is the web server listening on that address? If you don't want Let's Encrypt to use an IPv6 address, it should not be listed in DNS. Let's Encrypt is not really designed to offer certificates for dynamic DNS domains. Angus Share this post Link to post
idontknow 0 Posted September 13, 2021 Ah, ok. I replaced the automatic usage of dyn.org in the router by setting the update-url manually (members.dyndns.org/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG), so no ipv6-address will be set, now it's working. I'am still wondering why it worked on my side, where the router also sets both ipv4 and ipv6 addresses when making a DynDNS-Update and the ethernet-connection of my PC has been ipv6-disabled. Thank you very much for your hint, Angus! Share this post Link to post
Angus Robertson 574 Posted September 13, 2021 The logs on your own PC will tell you why it worked, probably Let's Encrypt tried the IPv4 address first, or both, not sure about the rules for checking multiple IP addresses in DNS records. The TSslX509Certs component accesses your local web server using DNS before starting the order to make sure it's available from the public internet, but ICS prefers IPv4 so would not check IPv6 first. Also, the check may not work when using NAT, I use a proxy server for such checks so I know access is from the internet. Angus Share this post Link to post