Let's Encrypt updatet nicht

[night2day]

Hallo Gemeinde,

mit Schrecken habe ich festgestellt, das mein Let's Encrypt Zertifikat nun schon eine gute Weile ausgelaufen ist.
Bisher hatte sich das Zertifikat immer automatisch verlängert.

Nun mäkelt er bei einer manuellen Verlängerung herum, das er den Domainnamen nicht authentisieren kann,
Sinngemäs, ich kanns nicht mehr im Wortlaut schreiben, da er mich vor lauter Versuchen nun gar nicht mehr mag.
"Die maximale Zahl der Zertifikatsanforderungen iswurde for diesen Domainnamen überschritten".

ich habe einne ?.diskstation.org Adresse, die auch funktioniert, nur das er halt wegen dem veralteten Zertifikat nörgelt.

Wie kann es sein, das Let's Encrypt plötzlich Probleme mit dem Namen hat nachdem es Jahrelang einwandfrei funktioniert hat.

Bin für jeden Tip zur Fehlersuche dankbar.

Gruß
n2d

 

[Uwe96]

Ports 80 und 443 sind freigegeben?

 

[Mahoessen]

schau mal mit der org. Fehlermeldung im lets encypt forum, dort haben mehrere den Fehler...

 

[diver68]

Nun mäkelt er bei einer manuellen Verlängerung herum...

Verlängern wird auch nicht mehr gehen, wenn es mal abgelaufen ist. Löschen und neu anlegen und o.g. Ports frei haben/machen.

Gruß

 

[night2day]

Hallo Uwe96

Port 80 hatte ich mal rausgeschmissen da ich connections nur noch über 443 (https) zulassen wollte. Ich probier das jetzt mal aus.

Gruß
n2d

 

[night2day]

Hallo zusammen,

hat tatsächlich mit Port 89 zu tun gehabt.
Ist mir zwar nicht wirklich klar warum ich Port 80 freigeben muss wenn eine Verbindung mit http
nicht wirklich erwünscht ist aber wenns denn sein muss...
Warum reicht da der 443 nicht?

Hat jemand eine Erklärung oder einen Link zu den Hintergrundwissen für diesen Kontext?

Gruß
Wolfgang

 

[Uwe96]

Wahrscheinlich benutzt das Zertifikat den Port 80.

 

[night2day]

Danke Euch für Eure Hilfe.

Gruß
n2d

 

[Fusion]

Das Zertifikat "benutzt" keinen Port.

Aber die Domain-Validierung http-01 von lets encrypt meistens schon
https://letsencrypt.org/how-it-works/
https://letsencrypt.org/docs/challenge-types/

Die Verlängerung bzw Ersetzung eines noch gültigen Zertifikats klappt oft auch nur mit 443 offen.
Eventuell gelten bei abgelaufenen Zertifikaten andere Regeln. Bin ich aber nicht auf dem neuesten Stand.

 

[luddi]

Die Verlängerung bzw Ersetzung eines noch gültigen Zertifikats klappt oft auch nur mit 443 offen.

Hi @Fusion,

hierzu auch meine Erfahrung.

Und zwar ging ich auch davon aus, dass bei noch gültigen Zertifikaten der Port 443 allein ausreicht.
Somit habe ich auf meinem System einen Cron erstellt welcher 1x pro Woche den Renew Request absetzt.

/usr/syno/sbin/syno-letsencrypt renew-all -vv

Mein Debug-Log zeigte mir aber, dass die Zertifikate nicht erneuert werden konnten und zwar aus besagtem Grund mit "http-01" über Port 80.

Hier ein Auszug aus dem Log:

{
      "type": "http-01",
      "status": "invalid",
      "error": {
        "type": "urn:ietf:params:acme:error:connection",
        "detail": "Fetching http://xxx.yyyyyy.tld/.well-known/acme-challenge/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx: Error getting validation data",
        "status": 400
      },

[...]

DEBUG: Failed to do challenge for xxx.yyyyyy.tld with type http-01.

--luddi

 

[rmayergfx]

Hallo, da ich im Moment mit einem ähnlichen Problem kämpfe: https://www.synology-forum.de/showthread.html?106743-Let%C2%92s-Encrypt-Zertifikate-%C3%BCber-Script-kein-Update, wie komme ich an das entsprechende Log?

 

[luddi]

Welches Log genau meinst du?

--luddi

 

[rmayergfx]

Welches Log genau meinst du?

--luddi

Das Log in dem du gesehen hast, das Port 80 geschlossen ist und daher das update nicht funktioniert. Ich bekomme nach der Ausführung des Scripts mit "/usr/syno/sbin/syno-letsencrypt renew-all -v" eine E-Mail, da sehe ich jedoch keine detaillierten Fehler mit drin, auch ein Ändern auf "/usr/syno/sbin/syno-letsencrypt renew-all -vv" wie es in manchen Threads zu finden ist hat keine Änderung gebracht. Wie schon in meinem Thread geschrieben, wird das Script zwar ausgeführt, ich sehe auch keine Fehler, aber es wird nicht wirklich aktualisiert. Aktualisiere ich manuell über die Ansicht der Zertifikate wird sofort das Enddatum aktualisiert.... Darum habe ich die Befürchtung, das dieses Script aktuell nicht wirklich funktioniert...

 

[luddi]

Also wenn du den Befehl in der Kommandozeile direkt ausführst

/usr/syno/sbin/syno-letsencrypt renew-all -vv

dann solltest du doch die Ausgabe direkt in der Konsole bekommen.

Wenn du den Aufgabenplaner dafür verwendest dann die Empfehlung die Ausgabe in eine Datei umzuleiten.

z.B.

/usr/syno/sbin/syno-letsencrypt renew-all -vv > /volume1/<SHARE>/logfile.txt

Die Optionsparameter die es zu dem syno-letsencrypt binary gibt:

~# /usr/syno/sbin/syno-letsencrypt
Copyright (c) 2003-2019 Synology Inc. All rights reserved.

syno-letsencrypt <command> [<args>]
  new-cert 
      -d [domains]   Domain name to be registed. (required)
      -m [mail]      Email address for contact. (required)
      -s [server]    Let's encrypt directory URL. (optional)
      -c [certid]    Certificat Id. (optional)
      -p [version]   ACME version, should use with -s (optional)

  renew-all

  revoke
     -c [cert-path]  revoke a certificat. (required)

For all command, you can add the following arguments for debug.
      -v             Show debug message.
      -vv            Show more debug message.

--luddi

 

[rmayergfx]

Dankeschön,

leider bekomme ich auch mit dem Parameter -vv nicht mehr angezeigt als das was in der Mail steht, auch im umgeleiteten logfile.txt steht nur folgendes:

DEBUG: Issuer name of certificate. [Synology Inc.]->[/usr/syno/etc/certificate/_archive/9U6EiU/cert.pem]
DEBUG: certificate is not issued by Let's encrypt. [/usr/syno/etc/certificate/_archive/9U6EiU/cert.pem]
DEBUG: Issuer name of certificate. [Let's Encrypt]->[/usr/syno/etc/certificate/_archive/zXMOgq/cert.pem]
DEBUG: cert is not expired. [/usr/syno/etc/certificate/_archive/zXMOgq]

Wäre es expired hätte ich ein richtiges Problem. Ich würde das jedoch gerne schon vorher per Script updaten, in der Systemsteuerung manuell funktioniert das ohne Probleme, d.h. ich kann sozusagen täglich manuell das Enddatum verlängern (was natürlich unsinnig ist). Mir kommt es so vor als würde das manuelle Update andere Befehle absetzten als das Script. Habe es gerade nochmals mit den o.g. Parametern erst über den Aufgabenplaner probiert und bin dann zu den Zertifikaten. Enddatum war immer noch 2020-06-20 wie in meinem gestarteten Thread. Manuell mit der rechten Maustaste aktualisieren....und siehe da, neues Enddatum 2020-06-22.

Mit dem geänderten Debug Befehl und der Umleitung in die Datei habe ich dafür nun das Problem das mir in der gesendeten E-Mail das Debug fehlt:

Sehr geehrter Benutzer,

Aufgabenplaner hat eine geplante Aufgabe abgeschlossen.

Aufgabe: Renew SSL Certificate
Startzeit: Tue, 24 Mar 2020 22:08:36 GMT
Stoppzeit: Tue, 24 Mar 2020 22:08:37 GMT
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:


Mit freundlichen Grüßen
Synology DiskStation

vorher:

Sehr geehrter Benutzer,

Aufgabenplaner hat eine geplante Aufgabe abgeschlossen.

Aufgabe: Renew SSL Certificate
Startzeit: Sun, 22 Mar 2020 00:00:02 GMT
Stoppzeit: Sun, 22 Mar 2020 00:00:03 GMT
Aktueller Status: 0 (Normal)
Standardausgabe/Fehler:
DEBUG: Issuer name of certificate. [Synology Inc.]->[/usr/syno/etc/certificate/_archive/9U6EiU/cert.pem]
DEBUG: certificate is not issued by Let's encrypt. [/usr/syno/etc/certificate/_archive/9U6EiU/cert.pem]
DEBUG: Issuer name of certificate. [Let's Encrypt]->[/usr/syno/etc/certificate/_archive/zXMOgq/cert.pem]
DEBUG: cert is not expired. [/usr/syno/etc/certificate/_archive/zXMOgq]


Mit freundlichen Grüßen
Synology DiskStation

 

[luddi]

Okay wie auch immer.

Deinem Log ist ja zu entnehmen dass es nicht abgelaufen sei.

DEBUG: cert is not expired. [/usr/syno/etc/certificate/_archive/zXMOgq]

Somit wird auch nicht versucht eine Kommunikation über Port 80 mit dem Mechanismus http-01 zu starten.
Eine Erneuerung meines Wissens ist soweit ich mich recht erinnern kann frühestens 30 Tage vor Ablauf des Zertifikats möglich (bitte korrigiert mich wenn ich falsch liege).

Ein Erzwingen des Renewals ist aber mit den verfügbaren commands und arguments "<command> [<args>]" nicht gegeben. Hier sehe ich zumindest kein "force" oder der gleichen.

Warum die GUI die Zertifikate vorher schon erneuern kann ist mir dann ein Rätsel. Verwendet die GUI wohl eine andere binary? Gute Frage...

--luddi

 

[rmayergfx]

Daher auch die Frage, ob man das mitloggen kann, was in der GUI für ein Befehl oder Script abgesetzt wird, da es ja offensichtlich schon vor der 30 Tages Frist erfolgreich funktioniert. Und da es für das Renewal keine Limits mehr gibt:https://letsencrypt.org/de/docs/rate-limits/ könnte man das Script getrost täglich laufen lassen, d.h. selbst wenn Letsenrcypt mal eine Downtime hätte oder anderweitig nicht erreichbar ist würde das Zertifikat auf jeden Fall erneuert werden.

 

[luddi]

Daher auch die Frage, ob man das mitloggen kann, was in der GUI für ein Befehl oder Script abgesetzt [...]

Wie bereits erwähnt ist mir hier nichts bekannt.

Und da es für das Renewal keine Limits mehr gibt:https://letsencrypt.org/de/docs/rate-limits/ könnte man das Script getrost täglich laufen lassen

Hierzu würde ich sagen, dass ein "Rate Limit" nichts direkt mit dem Renewal zu hat. Also nichts damit wie lange vorher man ein Zertifikat erneuern darf/kann.
Es besagt nur dass die Anzahl der neu zu erstellenden Zertifikate und auch das gleichzeitige Erneuern mehrerer Zertifikate auf eine faire Benutzung abzielt/begrenzt ist.

Let’s Encrypt provides rate limits to ensure fair usage [...]

[...] The main limit is Certificates per Registered Domain (50 per week).

Renewals are treated specially: they don’t count against your Certificates per Registered Domain limit, but they are subject to a Duplicate Certificate limit of 5 per week. [...]

--luddi

 

[rmayergfx]

Verlängerungen werden speziell behandelt: Sie werden nicht auf Ihr Zertifikat pro registrierter Domain-Limit angerechnet, unterliegen jedoch einem Duplikat-Zertifikat-Limit von 5 pro Woche. Hinweis: Verlängerungen wurden bis März 2019 gegen Ihr Zertifikat pro registrierter Domain-Limit angerechnet, jetzt jedoch nicht mehr.

Diesen Textbaustein meinte ich!

 

[luddi]

Ja aber das heißt nur dass eine Beschränkung an das Domain-Limit aufgehoben wurde.

Und ein Domain-Limit ist eben wie hier beschrieben definiert:

Das Hauptlimit ist Zertifikate pro registrierte Domain (50 pro Woche). Eine registrierte Domain ist, generell gesehen, der Teil der Domain, den Sie von einem Domainregistrar gekauft haben. Zum Beispiel, im Namen www.example.com, ist die registrierte Domain example.com. In new.blog.example.co.uk, ist die registrierte Domain example.co.uk. Wir benutzen die Public Suffix List, um die registrierte Domain zu berechnen.

Wenn Sie sehr viele Subdomains haben, möchten Sie vielleicht ein einfaches Zertifikat kombinieren, bis zu einem Limit von 100 Namen per Zertifikat. Kombiniert mit dem Limit darüber bedeutet das, Sie können Zertifikate für bis zu 5000 einzigartige Subdomains pro Woche ausstellen. Ein Zertifikat mit mehreren Namen wird oft SAN Zertifikat genannt, oder manchmal UCC Zertifikat. Hinweis: Aus Gründen der Leistung und Zuverlässigkeit sollten Sie nach Möglichkeit weniger Namen pro Zertifikat verwenden.

Und der Hinweis den du hier zitierst...

Verlängerungen wurden bis März 2019 gegen Ihr Zertifikat pro registrierter Domain-Limit angerechnet, jetzt jedoch nicht mehr.

...besagt doch nur dass ein Renewal nicht auf das Limit pro registrierte Domain (50 pro Woche) beschränkt ist.

--luddi