Let's Encrypt Problem

  • Hallo zusammen,


    da der Support am Wochenende leider nicht arbeitet, hoffe ich jemand hat eine Idee hierzu.

    Für den neuen BF2000er Tarif bin ich mit einer zusätzlichen Domain ins neue Paket umgezogen.

    Jetzt wollte ich das Let's Encrypt Zertifikat ausstellen, aber ich kriege immer Verbindungsfehler im Error Log.

    Weiterleitung HTTP -> HTTPS ist nicht aktiv.

    Bin echt ratlos. Danke für eure Tipps! Achso: Die neuen DNS Einträge sind schon längst aktiv


    Anbei ein anonymisiertes Fehlerprotokoll

    __

    SSL/TLS-Zertifikat konnte für zensiert.com nicht ausgestellt werden.

    Details:Let's Encrypt-SSL/TLS-Zertifikat konnte nicht ausgestellt werden für xxx.com. Die Autorisierung dieser Domain ist fehlgeschlagen.

    DetailsInvalid response from https://acme-v02.api.letsencry…cme/authz-v3/180852140127.


    Details:


    Type: urn:ietf:params:acme:error:connection


    Status: 400


    Detail: 202.61.232.190: Fetching "LINK" Connection refused

  • Ergänzung: In dem Let's Encrypt Link steht sowieso der Domainname und das bringt mich zu…

    Code
    $ curl -6vI http://<ZENSIERT>/.well-known/acme-challenge/-05JXZY2mcO0smI-wEPvKWX3K06Z0atBF3GCmlGxdqM
    *   Trying <ZENSIERT>::18:1164:80...
    * TCP_NODELAY set
    * connect to <ZENSIERT>::18:1164 port 80 failed: Verbindungsaufbau abgelehnt
    * Failed to connect to <ZENSIERT> port 80: Verbindungsaufbau abgelehnt
    * Closing connection 0
    curl: (7) Failed to connect to <ZENSIERT> port 80: Verbindungsaufbau abgelehnt

    Also tatsächlich "Connection refused". IPv6 ist kaputt, aber IPv4 funktioniert. :)


    Entweder stimmt die IPv6-Adresse des AAAA-Records nicht (bitte mit den Angaben aus dem CCP kontrollieren!) oder da ist beim Webserver etwas falsch konfiguriert. Letzteres könnte nur der Support beheben.


    Als Workaround könntest Du den AAAA-Record Deiner Domain einmal entfernen und es in einer halben Stunde nochmals versuchen.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    5 Mal editiert, zuletzt von KB19 ()

    Gefällt mir 1
  • Ergänzung: In dem Let's Encrypt Link steht sowieso der Domainname und das bringt mich zu…

    Code
    $ curl -6vI http://<ZENSIERT>/.well-known/acme-challenge/-05JXZY2mcO0smI-wEPvKWX3K06Z0atBF3GCmlGxdqM
    *   Trying <ZENSIERT>::18:1164:80...
    * TCP_NODELAY set
    * connect to <ZENSIERT>::18:1164 port 80 failed: Verbindungsaufbau abgelehnt
    * Failed to connect to <ZENSIERT> port 80: Verbindungsaufbau abgelehnt
    * Closing connection 0
    curl: (7) Failed to connect to <ZENSIERT> port 80: Verbindungsaufbau abgelehnt

    Also tatsächlich "Connection refused". :)


    Entweder stimmt die IPv6-Adresse des AAAA-Records nicht (bitte mit den Angaben aus dem CCP kontrollieren!) oder da ist beim Webserver etwas falsch konfiguriert. Letzteres könnte nur der Support beheben. Als Workaround könntest Du den AAAA-Record Deiner Domain einmal entfernen und es in einer halben Stunde nochmals versuchen.

    Danke ich prüfe / teste das später mal mit dem AAAA Record.

  • Doch, die AAAA Einträge passen. Vielleicht dauert es doch noch einfach etwas länger mit den DNS Einträgen, bis die Änderungen überall durch sind.

    War zuvor auf 86400 TTL gesetzt (Standard) Wobei Du hast ja auch eben auf die <ZENSIERT>::18:1164 IPv6 versucht.

    Das ist schon die richtige Adresse. Also liegt es doch nicht am DNS, dann keine Ahnung.

    Muss wohl der Support ran.

  • Den "zensierten" xxx-Link im ersten Beitrag würde ich übrigens lieber schnell entfernen. Nimm für so etwas example.com bzw. example.net als Platzhalter ;)


    Was halt auffällig ist in der Fehlermeldung, dass er versucht hat per HTTPS zu meiner Domain zu verbinden, oder ist das normal?

    Wie gesagt die Weiterleitung ist nicht aktiv konfiguriert für die Domain.

    Der leitet aber weiter…



    Doch, die AAAA Einträge passen. Vielleicht dauert es doch noch einfach etwas länger mit den DNS Einträgen, bis die Änderungen überall durch sind.

    War zuvor auf 86400 TTL gesetzt (Standard)

    Wenn dort die IPv6-Adresse 2a03:4000:61:36f4::18:1164 drinnen steht, ist die Änderung schon durch. Dann kann wirklich nur der Support helfen, weil der Webserver offenbar nicht auf die IPv6-Adresse reagiert.


    Mein genannter Workaround sollte dann allerdings trotzdem helfen, bis der Support es behebt.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    3 Mal editiert, zuletzt von KB19 ()

  • Also zumindest wenn das die Hauptdomain einer Inklusivdomain ist, wirst du den Haken wohl ohne Support nicht wegbekommen. Ist wohl leider so, früher mit Plesk Onyx ging das noch. ;) Früher war halt mehr Lametta. Bei einer Subdomain würde ich eventuell mal versuchen sie zu löschen und dann später wieder neu anzulegen, wenn der Apache nicht mehr darauf reagiert. Aber Vorsicht beim Löschen, eventuell bereits vorhandene Installation besser vorher in ein anderes Verzeichnis schieben und der Subdomain zugewiesenen Datenbanken auch mal die Zuweisung wegnehmen/ändern. Zur Sicherheit vorher einen SQL-Dump erzeugen (Export per phpMyAdmin oder was auch immer du für sowas nutzt). Nicht dass das schlaue Plesk dir da was zerschiesst/löscht beim Löschen der Subdomain.


    Ansonsten, was spricht gegen den Workaround von KB19 ? AAAA Eintrag erst mal rausnehmen, dann warten, bis LE bei der Erstellung per IPv4 verbindet. Solang ein AAAA Record vorhanden ist, wird der von LE bevorzugt. Und wenn der Server darauf dann nicht reagiert, klappt es halt nicht mit der Erstellung des Zertifikats.

  • Also zumindest wenn das die Hauptdomain einer Inklusivdomain ist, wirst du den Haken wohl ohne Support nicht wegbekommen. Ist wohl leider so, früher mit Plesk Onyx ging das noch. ;) Früher war halt mehr Lametta. Bei einer Subdomain würde ich eventuell mal versuchen sie zu löschen und dann später wieder neu anzulegen, wenn der Apache nicht mehr darauf reagiert. Aber Vorsicht beim Löschen, eventuell bereits vorhandene Installation besser vorher in ein anderes Verzeichnis schieben und der Subdomain zugewiesenen Datenbanken auch mal die Zuweisung wegnehmen/ändern. Zur Sicherheit vorher einen SQL-Dump erzeugen (Export per phpMyAdmin oder was auch immer du für sowas nutzt). Nicht dass das schlaue Plesk dir da was zerschiesst/löscht beim Löschen der Subdomain.


    Ansonsten, was spricht gegen den Workaround von KB19 ? AAAA Eintrag erst mal rausnehmen, dann warten, bis LE bei der Erstellung per IPv4 verbindet. Solang ein AAAA Record vorhanden ist, wird der von LE bevorzugt. Und wenn der Server darauf dann nicht reagiert, klappt es halt nicht mit der Erstellung des Zertifikats.

    IPv6 ist doch nicht das Problem sondern die HTTPS Umleitung dachte ich?

  • Nein, IPv6 ist das Hauptproblem! Der Webserver reagiert darauf nicht ("Connection refused") ;)


    Siehe: https://forum.netcup.de/netcup…crypt-problem/#post190132

    Lesen will gelernt sein :D AAAA Einträge entfernt. TTL ist zum Glück auf 5min noch eingestellt gewesen. Bin gespannt

    Update: Wow...es hat tatsächlich geklappt.

    Ich stand etwas auf der Leitung aber Danke für den tollen Workaround!

  • TTL ist zum Glück auf 5min noch eingestellt gewesen.

    Hinweis am Rande: Das ist Let's Encrypt egal, die fragen soweit ich weiß direkt die zuständigen Nameserver bzw. über einen eigenen Resolver, der alles maximal 60 Sekunden im Cache hält. :)


    Sobald die Zone also neugeladen wurde, was bei netcup alle 10 Minuten passiert, wandert der Status im CCP in jeder Zeile auf "yes" und die Änderung sollte LE bekannt sein.


    Ich stand etwas auf der Leitung aber Danke für den tollen Workaround!

    Perfekt :)


    Dem Support würde ich es halt trotzdem noch melden, dass Deine IPv6-Adresse auf Port 80/443 nicht reagiert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Einmal editiert, zuletzt von KB19 ()

  • Interessant mit dem eigenen LE Resolver :) Ja genau, hatte ich schon gemacht mit dem Support. Der Workaround löst ja nicht das eigentliche IPv6 Problem.