ich habe grundsätzlich das gleiche Probleme wie hier beschrieben.
Allerdings geht es um eine Sub(Sub)domain, die schon etwas länger existiert (5-6 Monate). Ein Aufruf der Adresse im Browser und Intenetanschluss der der Wahl ist problemlos möglich.
Fehlereldung im Protokoll:
Code: Select all
[25-Nov-2019 00:01:02] INFO --> Using certificate authority: "https://acme-v02.api.letsencrypt.org/" (LIVE).
[25-Nov-2019 00:01:02] INFO --> Getting endpoint URLs.
[25-Nov-2019 00:01:02] INFO --> Account "server02-cockpit" already registered. Continue.
[25-Nov-2019 00:01:02] INFO --> Requesting Key ID.
[25-Nov-2019 00:01:02] INFO --> Sending signed request to "https://acme-v02.api.letsencrypt.org/acme/new-acct".
[25-Nov-2019 00:01:03] INFO --> Start certificate generation.
[25-Nov-2019 00:01:04] ERROR --> a lets encrypt error occurred: Local resolving checks failed for domain "cockpit.server02.x.y".
Ja, nachstehend die Prüfungen meinerseits direkt auf dem Server via SSH.Martin wrote: local resolv check ist ein interner Check, kann der Server selbst die Domain denn korrekt auflösen?
Code: Select all
root@server02:~# nslookup cockpit.server02.x.y
Server: 127.0.0.53
Address: 127.0.0.53#53
Non-authoritative answer:
cockpit.server02.x.y canonical name = server02.x.y.
Name: server02.x.y
Address: 127.0.1.1
Code: Select all
root@server02:~# ping cockpit.server02.x.y
PING server02.x.y (127.0.1.1) 56(84) bytes of data.
64 bytes from server02.x.y (127.0.1.1): icmp_seq=1 ttl=64 time=0.046 ms
64 bytes from server02.x.y (127.0.1.1): icmp_seq=2 ttl=64 time=0.044 ms
64 bytes from server02.x.y (127.0.1.1): icmp_seq=3 ttl=64 time=0.066 ms
64 bytes from server02.x.y (127.0.1.1): icmp_seq=4 ttl=64 time=0.080 ms
^C
--- server02.x.y ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3071ms
rtt min/avg/max/mdev = 0.044/0.059/0.080/0.014 ms
Jolinar wrote:wget -6 https://install.keyhelp.de/testfile100M.bin
Code: Select all
root@server02:~# wget -6 https://install.keyhelp.de/testfile100M.bin
--2019-11-25 09:15:31-- https://install.keyhelp.de/testfile100M.bin
Resolving install.keyhelp.de (install.keyhelp.de)... 2001:1b60:2:11:913:101:be57:cafe
Connecting to install.keyhelp.de (install.keyhelp.de)|2001:1b60:2:11:913:101:be57:cafe|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘testfile100M.bin’
testfile100M.bin 100%[========================================================================================================================================>] 100.00M 54.1MB/s in 1.8s
2019-11-25 09:15:33 (54.1 MB/s) - ‘testfile100M.bin’ saved [104857600/104857600]
root@server02:~# wget -4 https://install.keyhelp.de/testfile100M.bin
--2019-11-25 09:15:38-- https://install.keyhelp.de/testfile100M.bin
Resolving install.keyhelp.de (install.keyhelp.de)... 62.141.56.232
Connecting to install.keyhelp.de (install.keyhelp.de)|62.141.56.232|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 104857600 (100M) [application/octet-stream]
Saving to: ‘testfile100M.bin.1’
testfile100M.bin.1 100%[========================================================================================================================================>] 100.00M 37.2MB/s in 2.7s
2019-11-25 09:15:41 (37.2 MB/s) - ‘testfile100M.bin.1’ saved [104857600/104857600]
Nein, iptables.Jolinar wrote: Ergänzende Fragen:
Steht der Server hinter einer Firewall?
Wird der Zugriff über einen Proxy realisiert?
Ist IPv6 korrekt eingerichtet?
Nein.
Ja.
Standardmäßig ist die DNS-Zone für die Domain deaktiviert. Ich habe für meine Tests temporär den Parameter "DNS für diese Domain deaktivieren" wieder deaktivert. Leider bleibt das Ergebnis das Selbe.
Gruß,
Dani