[gelöst] LE Certifikat für ISPC Pabel/Mail/FTP geht nicht (Setup Vorgang)

DarkTrinity

Member
Hallo liebe Community,

ich krieg die Krise ! Ich versuche einen Server neu aufzusetzen und verwende dieses Tutorial:
The Perfect Server - Ubuntu 20.04 with Apache, PHP, MariaDB, PureFTPD, BIND, Postfix, Dovecot and ISPConfig 3.2

Bei der Installation von ISPC kommt es bei der Generierung des LE- Zertifikats (für ISPC Panel) zu folgendem Fehler - immer und immer wieder:

Challenge failed for domain host.domain.tld
http-01 challenge for host.domain.tld
Cleaning up challenges

Some challenges have failed.

Exakte Ausgabe hier:

Code:
Create new ISPConfig SSL certificate (yes,no) [no]: yes

Checking / creating certificate for host.domain.tld
Using certificate path /etc/letsencrypt/live/host.domain.tld
Using apache for certificate validation
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Plugins selected: Authenticator webroot, Installer None
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for host.domain.tld
Using the webroot path /usr/local/ispconfig/interface/acme for all unmatched domains.
Waiting for verification...
Challenge failed for domain host.domain.tld
http-01 challenge for host.domain.tld
Cleaning up challenges
Some challenges have failed.
Issuing certificate via certbot failed. Please check log files and make sure that your hostname can be verified by letsencrypt
Could not issue letsencrypt certificate, falling back to self-signed.
aus der Log entnehme ich folgendes (PS: wieso steht da nginx obwohl ich Apache nutze):

Code:
2022-01-09 08:35:13,628:DEBUG:urllib3.connectionpool:https://acme-v02.api.letsencrypt.org:443 "POST /acme/authz-v3/66486723920 HTTP/1.1" 200 809
2022-01-09 08:35:13,628:DEBUG:acme.client:Received response:
HTTP 200
Server: nginx
Date: Sun, 09 Jan 2022 08:35:13 GMT
Content-Type: application/json
Content-Length: 809
Connection: keep-alive
Boulder-Requester: 355120090
Cache-Control: public, max-age=0, no-cache
Link: <https://acme-v02.api.letsencrypt.org/directory>;rel="index"
Replay-Nonce: 0102DI7_fgO2_fPi9HPwJovvMMBqThA9FbXBYmSdP1Sd8QI
X-Frame-Options: DENY
Strict-Transport-Security: max-age=604800

{
  "identifier": {
    "type": "dns",
    "value": "host.domain.tld"
  },
  "status": "pending",
  "expires": "2022-01-16T08:35:11Z",
  "challenges": [
    {
      "type": "http-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/66486723920/gufPhQ",
      "token": "fLVrxLNChSVMQUg1ZSk5o6DWOu6nWcrt38Sdg3IkK9c"
    },
    {
      "type": "dns-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/66486723920/lIyfSw",
      "token": "fLVrxLNChSVMQUg1ZSk5o6DWOu6nWcrt38Sdg3IkK9c"
    },
    {
      "type": "tls-alpn-01",
      "status": "pending",
      "url": "https://acme-v02.api.letsencrypt.org/acme/chall-v3/66486723920/04r0sg",
      "token": "fLVrxLNChSVMQUg1ZSk5o6DWOu6nWcrt38Sdg3IkK9c"
    }
  ]
}

2022-01-09 08:35:16,785:DEBUG:acme.client:Storing nonce: 0101Biv-__Oc6zIRZT4p9IElbc-uuBKK-CM5g8ZRKzdZsPs
2022-01-09 08:35:16,785:WARNING:certbot.auth_handler:Challenge failed for domain host.domain.tld
2022-01-09 08:35:16,785:INFO:certbot.auth_handler:http-01 challenge for host.domain.tld
2022-01-09 08:35:16,785:DEBUG:certbot.reporter:Reporting to user: The following errors were reported by the server:

Domain: host.domain.tld
Type:   unauthorized
Detail: Invalid response from http://host.domain.tld/.well-known/acme-challenge/fLVrxLNChSVMQUg1ZSk5o6DWOu6nWcrt38Sdg3IkK9c [1.2.3.4]: "<!DOCTYPE HTML PUBLIC \"-//IETF//DTD HTML 2.0//EN\">\n<html><head>\n<title>404 Not Found</title>\n</head><body>\n<h1>Not Found</h1>\n<p"

To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address.
2022-01-09 08:35:16,786:DEBUG:certbot.error_handler:Encountered exception:
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.

2022-01-09 08:35:16,786:DEBUG:certbot.error_handler:Calling registered functions
2022-01-09 08:35:16,786:INFO:certbot.auth_handler:Cleaning up challenges
2022-01-09 08:35:16,786:DEBUG:certbot.plugins.webroot:Removing /usr/local/ispconfig/interface/acme/.well-known/acme-challenge/fLVrxLNChSVMQUg1ZSk5o6DWOu6nWcrt38Sdg3IkK9c
2022-01-09 08:35:16,786:DEBUG:certbot.plugins.webroot:All challenges cleaned up
2022-01-09 08:35:16,786:DEBUG:certbot.log:Exiting abnormally:
Traceback (most recent call last):
  File "/usr/bin/certbot", line 11, in <module>
    load_entry_point('certbot==0.40.0', 'console_scripts', 'certbot')()
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1382, in main
    return config.func(config, plugins)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 1265, in certonly
    lineage = _get_and_save_cert(le_client, config, domains, certname, lineage)
  File "/usr/lib/python3/dist-packages/certbot/main.py", line 121, in _get_and_save_cert
    lineage = le_client.obtain_and_enroll_certificate(domains, certname)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 417, in obtain_and_enroll_certificate
    cert, chain, key, _ = self.obtain_certificate(domains)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 348, in obtain_certificate
    orderr = self._get_order_and_authorizations(csr.data, self.config.allow_subset_of_names)
  File "/usr/lib/python3/dist-packages/certbot/client.py", line 396, in _get_order_and_authorizations
    authzr = self.auth_handler.handle_authorizations(orderr, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 91, in handle_authorizations
    self._poll_authorizations(authzrs, max_retries, best_effort)
  File "/usr/lib/python3/dist-packages/certbot/auth_handler.py", line 180, in _poll_authorizations
    raise errors.AuthorizationError('Some challenges have failed.')
certbot.errors.AuthorizationError: Some challenges have failed.
Die DNS stimmt aber - hier ein Screenshot der Settings beim Provider 1blu (hier nicht sichbar: die beiden, sehr wohl integrierten NS Server des Providers):
1009

Meine /etc/hosts:
Code:
127.0.0.1 localhost

# The following lines are desirable for IPv6 capable hosts
#::1     ip6-localhost ip6-loopback
#fe00::0 ip6-localnet
#ff00::0 ip6-mcastprefix
#ff02::1 ip6-allnodes
#ff02::2 ip6-allrouters

1.2.3.4 host.domain.tld host
Das komische ist - wenn ich in ISPC eine Webseite anlege, dann klappt das LE Zertifikat für diese Webseite, wenn ich es erstelle. Habe ich getestet.Aber das Erstellen des LE-Zertifikates für das ISPC Panel, bei der Installation klappt einfach nicht.

Ich werde dieses Tutorial nun zum 5. male durchgehen und weiß eigentlich genau daß es wieder nicht klappen wird. :mad:

Was bedeutet diese Meldung ? Es kann doch nicht so schwer sein, andere schaffen das doch auch.... Der Provider 1blu ist natürlich absolut sch...., der Konfigurationsbereich für die DNS ist voll komisch, finde ich.

Aber das @ steht als Container für die Domain. Wenn ich das @ weglasse und die DOmain ausschreibe geht fast garnix mehr.
Die PTR wurde von 1Blu bereits gesetzt und zwar korrekt(host.domain.tld).

Vielleicht kann mir ja jemand verraten wo das Problem ist, denn ich selbst bin ja offenbar nicht in der Lage dazu :(
 
Zuletzt bearbeitet:

DarkTrinity

Member
Mittlerweile hat sich aber von selbst was getan was gestern noch nicht war:

Rufe die FQDN des Hosts auf, wird auf https weitergeleitet und ich sehe eine 1Blu Seite, die ganz bestimmt keine Standard Apache Hostseite ist:
1010


Und wenn ich mit dem "FireFox Developer Edition", wo kein "HTTPS Only" konfiguriert ist, explizit die Adresse "http://host.domain.tld:80" aufrufe bekomme ich eine Index :eek::oops::rolleyes:o_O:confused:

1011

Was soll das denn jetzt ? Sowas habe ich echt noch nie gesehen (und ich hab schon viel gesehen)


Bei der Index Seite könnte ich mir ja vielleicht noch vorstellen, daß es der Apps- Host von ISPC ist (wo ich natürlich nichts hinterlegt habe, daher auch leer). Wirklich wissen tue ich das aber nicht, vermute es nur.

Und diese 1Blu bewertungsseite - wo die wohl plötzlich her kommt ???? Ö.Ö
 

Strontium

Member
Vielleicht kann mir ja jemand verraten wo das Problem ist,
Beim DNS - steht eh in der Fehlermeldung oben.

Ich werde dieses Tutorial nun zum 5. male durchgehen und weiß eigentlich genau daß es wieder nicht klappen wird
Versuch doch mal den Autoinstaller von ISPConfig: https://forum.howtoforge.de/threads/die-installscripts.12445/
 
die erste Frage - was gibt ein dig all Domain aus... mift edit Strontium war schneller.
dann sieht schon mal ein bisschen. am besten noch die ns von 1blu befragen. :)

meine Einstellungen bei 1blu sehen aber leicht anders aus... :)
1012
 

Strontium

Member
Oder noch besser: die Nameserver befragen, die LetsEncrypt befrägt. Weil wenn die nämlich noch nichts wissen von den 1blue-Einstellungen kommt es zu dieser Fehlermeldung wie oben beschrieben.

Der Provider 1blu ist natürlich absolut sch...., der Konfigurationsbereich für die DNS ist voll komisch, finde ich.
Oder am besten: die Nameserver von Cloudflare verwenden als Primary DNS. Dann hast du nämlich keinen Stress wenn du den Hostingprovider wechselst.
 

DarkTrinity

Member
die erste Frage - was gibt ein dig all Domain aus... mift edit Strontium war schneller.
dann sieht schon mal ein bisschen. am besten noch die ns von 1blu befragen. :)

meine Einstellungen bei 1blu sehen aber leicht anders aus... :)
Den Anhang 1012 betrachten
Ja, Deine DNS sieht anders aus wil IPV6 drinne ist (AAAA) und bei mir nicht.
Auch nutzt Du die Sternchen als Platzhalter - die bewirken daß jeder Host erreichbar ist - im Zweifelsfall über die Defaultpage. Und Du hast mehrere Server im Einsatz (weil mehrere IPs) bei mir macht alles dieses eine Gerät.
Aber ich habe kein IPV6 und ich möchte auch keine Wildcard für Hosts - muss man meines Wissens nach auch nicht

Dig Befejl

Code:
dig all domain.tld

; <<>> DiG 9.16.6 <<>> all domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40106
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;all.                           IN      A

;; AUTHORITY SECTION:
.                       85745   IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2022010900 1800 900 604800 86400

;; Query time: 4 msec
;; SERVER: 1<lan ip>#53(<lan ip>)
;; WHEN: So Jan 09 14:04:56 CET 2022
;; MSG SIZE  rcvd: 107

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40499
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;domain.tld.       IN      A

;; ANSWER SECTION:
domain.tld. 10219  IN      A       <serverip>

;; Query time: 0 msec
;; SERVER: <ip lan>#53<ip lan>
;; WHEN: So Jan 09 14:04:56 CET 2022
;; MSG SIZE  rcvd: 68
Wie ich mit dig die 1blu ns befragen sollrte weiss ich nicht - müsste mal gucken ...

Oder noch besser: die Nameserver befragen, die LetsEncrypt befrägt. Weil wenn die nämlich noch nichts wissen von den 1blue-Einstellungen kommt es zu dieser Fehlermeldung wie oben beschrieben.
Du meinst ich soll einfach abwarten und neu versuchen ? Welche NS von LE befragt werden weiss icha us dem Stehgreif natürlich nicht
 
Zuletzt bearbeitet:

DarkTrinity

Member
Hmmm, ok, die sind noch nicht ganz rum.... Bei Hetzner gings aber echt schneller meistens....

Ich hab nun mal wie folgt analysiert:

1. Bei welchen Nameservern ist der Host (entspr. PTR) ?
Code:
desk:/home/nuria # dig ns host.domain.tld

; <<>> DiG 9.16.6 <<>> ns host.domain.tld
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61660
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;host.domain.tld.  IN      NS

;; AUTHORITY SECTION:
host.domain.tld. 1800   IN      SOA     ns01.1blu.de. hostmaster.1blu.de. 2022010903 43200 5400 604800 86400

;; Query time: 20 msec
;; SERVER: 192.168.x.x#53(192.168.x.x)
;; WHEN: So Jan 09 15:58:17 CET 2022
;; MSG SIZE  rcvd: 116
Ok, es sind also ns01.1blu.de sowie hostmaster.1blu.de involviert.

Ich stelle nebenbei fest das stimmt nicht mit den Ausgaben des Kundenbereiches überein, wo es ns02.1blu.de sein solle (anstelle von hostmaster.1blu.de) - siehe Screenshot

1013


Egal - ok. Ich vertraue de, Dig- Kommando mehr als dem Kundenpanel - also gucken wir mal wie gut diese beiden Nameserver aus der Ausgabe des dig- Befehls oben meine Server- FQDN kennen. Wie man unten sieht kennt "NS01" meinen Server sehr wohl, während "Hostmaster" mit dem dig- Befehl nicht sprechen mag - wahrscheinlich ist er down:

Für NS01:
Code:
dig @ns01.1blu.de host.domain.tld

; <<>> DiG 9.16.6 <<>> @ns01.1blu.de host.domain.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37052
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;host.domain.tld.  IN      A

;; ANSWER SECTION:
host.domain.tld. 86400 IN  A       <SERVERIP>

;; Query time: 24 msec
;; SERVER: 87.238.195.66#53(87.238.195.66)
;; WHEN: So Jan 09 16:06:02 CET 2022
;; MSG SIZE  rcvd: 73
Für Hostmaster
Code:
desk:/home/nuria # dig @hostmaster.1blu.de host.domain.tld

; <<>> DiG 9.16.6 <<>> @hostmaster.1blu.de host.domain.tld
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Ok .... Einer der Nameserver kennt mich, der andere nicht. Eigentlich sollte ja wegen dem Primary/Secondary Prinzip trotzdem Erreichbarkeit gegeben sein.

Egal, neugierig wie ich bin befrage ich mal NS2, der ja laut Kundenbereich zuständig ist und laut dig-Befehlsausgabe ja nicht:
Code:
desk:/home/nuria # dig @ns02.1blu.de host.domain.tld

; <<>> DiG 9.16.6 <<>> @ns02.1blu.de host.domain.tld
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48249
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1680
;; QUESTION SECTION:
;host.domain.tld.  IN      A

;; ANSWER SECTION:
host.domain.tld. 86400 IN  A       <SERVERIP>

;; Query time: 20 msec
;; SERVER: 178.254.5.130#53(178.254.5.130)
;; WHEN: So Jan 09 16:13:41 CET 2022
;; MSG SIZE  rcvd: 73
NS2 kennt mich - ist aber eigentlich nicht zuständig... Ich finde das verwirrend, diese Diskrepanz zwischen der Ausgabe meiner Dig- Kommandos und den Angaben im Kundencenter. Und ich finde es komisch, daß bei Abruf meiner FQDN eine 1Blu Seite zu Kundenbefragungen gezeigt wird :(

Vielleicht liegt es daran, daß der andere Nameserver (hostmaster.1blu.de) down ist. Vielleicht weil die 48h noch nicht ganz herum sind.... Aber alles in allem finde ich das alles schon komisch ....

Was mache ich denn nu ? Bis morgen abend warten, nochmal die NS Server mit der Unixshell befragen ? Und dann am besten nochmal alles neu aufsetzen (noch ist es ja nicht viel) ... ?
 

DarkTrinity

Member
Ok, ich übe mich in Geduld - ist ja eine meine größten Stärken *Ironie off*

Und ein ganz liebes Danke an alle die geschrieben haben. Der Tip mit dem dig- Befehl geziehlt einen bestimmten NS Server anzusprechen war übrigens klasse. Wieder was ziemlich praktisches dazu gelernt. Diesen Parameter habe ich vorher noch nie benutzt

Mal sehen wie es weiter geht - so lange lasse ich den Thread erstmal offen
 
tja viele Meinungen welche Werte befragt werden müssen. :)
ich habe mir für dig dennoch meist den ( ja veralteten ) ALL angewöhnt...
der ist etwas gesprächiger....
damit sieht man auch welche NS involviert sind.... und welche TTL gesetzt wurde.

hostmaster ist eine Mailadresse, die nicht im üblichen Format mit @ geschrieben ist.. sondern mit einem Punkt. ist die zuständige Person/System dass für den Eintrag verantwortlich ist...

Ich bitte dennoch mal meine Einträge anzuschauen,
bei 1blu habe ich keinen Hostnamen in meinen Default Werten stehen...
Die IPv6 kannst gerne ignorieren, wenn bei deinem Server das nicht zum Einsatz kommt.. obwohl das eigentlich schon sein sollte. zumindest bin ich da ein Vertreter von :)
 

DarkTrinity

Member
Ich habe mir Deine NS Records doch angesehen, auch dazu geschrieben
Ja, Deine DNS sieht anders aus wil IPV6 drinne ist (AAAA) und bei mir nicht.
Auch nutzt Du die Sternchen als Platzhalter - die bewirken daß jeder Host erreichbar ist - im Zweifelsfall über die Defaultpage. Und Du hast mehrere Server im Einsatz (weil mehrere IPs) bei mir macht alles dieses eine Gerät.
Aber ich habe kein IPV6 und ich möchte auch keine Wildcard für Hosts - muss man meines Wissens nach auch nicht
[...]
Ich sehe aber in meinen Records nach wie vor keinen Fehler. Die IPs, Host & FQDN habe ich eben rausgeschnitten mit KPaint aber man sollte ja erkennen können was ich aufgesetzt habe.

Hostmaster hatte ich auf den NS Server von 1Blu bezogen (hostmaster.1blu.de). Der ist übrigens pingbar (wie ich eben getestet habe), also nicht down also kennt er wohl meine FQDN (noch) nicht.
Trotzdem sollte es laut Kundenpanel n02.1blu.de sein und eben nicht hostmaster.1blu.de . Das meinte ich mit Diskrepanz zwischen Dig- Ausgabe und 1Blu-Kundenpanel

Und was IPV6 angeht stimme ich Dir absolut zu - wird Zeit für den Switchover. Aber viele Mobilfunkanbieter addressieren noch auf IPV4 (noch nicht mal DS oder DS lite) .... Viele Firmen zahlen Geld für statisches IPV4.... So schnell wird sich das wohl nicht ändern
 

DarkTrinity

Member
hostmaster.1blu.de ist ein DNS-Proxy ^^ Was es alles gibt :D Vielleicht mag der ja deswegen nicht mit dem dig- Kommando sprechen ^^ Jedenfalls ist die Kundenanfrage nicht mehr da, wenn ich die FQDN meines Servers abrufe.

Heute abend sehe ich mir das genauer an. Aber glaube vorsichtig daß es jetzt wohl gehen müsste wahrscheinlich :cool:
 

DarkTrinity

Member
Eben mal nachgeguckt - beim Provider hatte das A Record eine falsche IP - ich bin doch nicht blöd, ich habe da auf jeden Fall die richtige IP eingegen ^^ Nu kann ich wieder 48 h warten ^^ Ich habe jetzt jeden einzelen schei** Record einzeln nochmal geschrieben und gespeichert - alle einzeln. Im Moment sind sie richtig ^^ Ich hoffe das bleibt auch so. Langsam reichst mir ^^
 

DarkTrinity

Member
Jetzt sagt er nach dem Update folgendes - aber die Fehlermeldung ist weg:
Code:
Cert not yet due for renewal
Keeping the existing certificate
Mir reichts - ich mach die Kiste platt und installiere neu
 

Werbung

Top