Letsencrypt-Zertifikat konnte nicht erneuert werden

Ich glaube, es ist Jahre her, seit ich ein Let’s-Encrypt-Zertifikat gesehen habe, das sich nicht erneuern ließ, aber in den letzten ein bis zwei Wochen hatte ich drei Websites mit veralteten Zertifikaten. Ein Rebuild behebt das Problem, und bisher habe ich es versäumt, in den Logs nach Hinweisen zu suchen.

Beim nächsten Mal werde ich etwas mehr unternehmen, um das Problem zu diagnostizieren, bevor ich die Website repariere.

Bitte beachten Sie:

Danke, Daniela! Das scheint tatsächlich damit zusammenzuhängen, aber ich weiß nicht, was ich dagegen tun soll oder wie ich feststellen kann, ob eine Website gezwungen werden muss, ein neues Zertifikat zu erhalten. Ich habe gerade einige Websites überprüft, und mehrere haben in den letzten Tagen erneuert. Ich glaube, in allen Fällen war das Zertifikat abgelaufen (ich habe nur das eine, das ich gerade repariert habe, noch einmal überprüft). Je mehr ich darüber nachdenke, desto weniger glaube ich, dass dies die Erklärung ist – es sei denn, einige dieser Websites hatten ein so altes Basis-Image, dass es nicht in der Lage war, ein neues Zertifikat abzurufen, weil dieses Basis-Image ein veraltetes Root-Zertifikat enthielt?

Ah! Das könnte es erklären. Eine andere docker-basierte Debian-9-Website, die ich betreue, erhält Fehler bei der Verwendung von curl, weil ihr Basis-Image fehlerhaft ist.

Wie alt ist das Discourse-Basis-Image auf diesen Seiten? Bitte teilen Sie den genauen Image-Tag mit.

Hier ist die Liste der Bilder von der Site, die ich gerade aktualisiert habe (sieht so aus, als wäre es Zeit für ein ./launcher cleanup!). Ich nehme also an, es war 2.0.20210528-1735?


REPOSITORY                      TAG                 IMAGE ID            CREATED             SIZE
local_discourse/app             latest              dab985be22b0        17 minutes ago      2.84GB
discourse/base                  2.0.20210528-1735   482386bf57af        4 months ago        2.36GB
<none>                          <none>              38be7702e0fc        5 months ago        2.75GB
discourse/base                  2.0.20210415-1332   30e4746e631e        5 months ago        2.23GB
discourse/base                  2.0.20201221-2020   c0704d4ce2b4        9 months ago        2.11GB
discourse/base                  2.0.20201004-2310   b64c37d7ab06        12 months ago       2.4GB
discourse/base                  2.0.20200429-2110   dc919e1dae2c        17 months ago       2.13GB
local_discourse/mail-receiver   latest              711fb527de35        21 months ago       128MB
discourse/base                  2.0.20191219-2109   4a99baef7044        21 months ago       2.23GB
discourse/mail-receiver         release             06fe375fe2c8        22 months ago       128MB
discourse/base                  2.0.20190901-2315   10f636afbeaf        2 years ago         2.29GB
discourse/base                  2.0.20190625-0946   2b3a5b47565f        2 years ago         1.93GB
discourse/base                  2.0.20190505-2322   ed87227f60d2        2 years ago         1.91GB
discourse/base                  2.0.20190321-0122   7db99586b5b5        2 years ago         1.97GB
discourse/mail-receiver         1.1.2               44042627246b        4 years ago         142MB

Hier sind die Zertifikatsinformationen für das letzte Zertifikat:

Ausgestellt am	Samstag, 26. Juni 2021 um 19:31:09 Uhr
Ablaufdatum	Freitag, 24. September 2021 um 19:31:08 Uhr

Es scheint jedoch nicht alle oder viele Sites zu betreffen.

Richtig. Das ist schon das dritte Mal, dass es passiert ist, und jedes Mal hatte ich es als Priorität gesetzt, die Site wieder online zu bringen. Beim nächsten Mal werde ich versuchen, bessere Notizen zu machen.

Man sieht die Aufrufe von acme.sh in den Logs, aber die Ausgabe wird nach /dev/null umgeleitet.

Ah, die Informationen gehen hier also verloren. Wir müssten wissen, welche Quelle die übergeordnete Ebene des alten local_discourse/app war.

Ich habe eine Testseite mit dem neuesten Image, und das Zertifikat wurde letzte Woche problemlos erneuert.

Ja. Und ich habe gerade ein Dutzend weitere überprüft, und die sind ebenfalls in Ordnung.

Ich hätte das wohl mit #mystery markieren sollen.

Ich habe das gleiche Problem. Einfach neu aufbauen, aber mein Let’s Encrypt-Zertifikat für Discourse wird nicht erneuert. Wie kann ich meine Installation überprüfen?

Gelöst: Neuaufbau und Warten

Aha! Es ist dieser Fehler im Zusammenhang mit der Verwendung von ZeroSSL als Standard-CA. Jetzt erinnere ich mich, dass dies in der jüngeren Vergangenheit ein Problem war.

Hier ist eine Instanz, die ich noch nicht neu erstellt habe:

root@community:~# docker ps
CONTAINER ID   IMAGE                           COMMAND        CREATED        STATUS      PORTS                                      NAMES
9b97fe9b5c22   local_discourse/web_only        "/sbin/boot"   9 months ago   Up 5 days   0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp   web_only
b3eae8a90cd7   local_discourse/mail-receiver   "/sbin/boot"   9 months ago   Up 5 days   0.0.0.0:25->25/tcp                         mail-receiver
5e90805e6d0d   local_discourse/data            "/sbin/boot"   9 months ago   Up 5 days                                              data
root@community:~# docker images
REPOSITORY                      TAG                 IMAGE ID       CREATED         SIZE
local_discourse/web_only        latest              ffd890f053e7   9 months ago    2.39GB
local_discourse/mail-receiver   latest              0d49c641ca25   9 months ago    128MB
<none>                          <none>              e53ed7c5db0f   9 months ago    2.34GB
local_discourse/data            latest              8c1539b06db4   9 months ago    2.15GB
discourse/base                  2.0.20201221-2020   c0704d4ce2b4   9 months ago    2.11GB
discourse/base                  2.0.20201208-1739   9da970f9c0bd   9 months ago    2.1GB
discourse/mail-receiver         release             06fe375fe2c8   22 months ago   128MB

Und wenn ich den acme-Befehl im Container ausführe, erhalte ich Folgendes:

root@community-web-only:/# "/shared/letsencrypt"/acme.sh --cron --home "/shared/letsencrypt" 
[Mon 04 Oct 2021 02:01:39 PM UTC] ===Starting cron===
[Mon 04 Oct 2021 02:01:39 PM UTC] Already uptodate!
[Mon 04 Oct 2021 02:01:39 PM UTC] Upgrade success!
[Mon 04 Oct 2021 02:01:39 PM UTC] Auto upgraded to: 3.0.1
[Mon 04 Oct 2021 02:01:39 PM UTC] Renew: 'community.thedaily9.in'
[Mon 04 Oct 2021 02:01:41 PM UTC] Using CA: https://acme.zerossl.com/v2/DV90
[Mon 04 Oct 2021 02:01:41 PM UTC] No EAB credentials found for ZeroSSL, let's get one
[Mon 04 Oct 2021 02:01:41 PM UTC] acme.sh is using ZeroSSL as default CA now.
[Mon 04 Oct 2021 02:01:41 PM UTC] Please update your account with an email address first.
[Mon 04 Oct 2021 02:01:41 PM UTC] acme.sh --register-account -m my@example.com
[Mon 04 Oct 2021 02:01:41 PM UTC] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Mon 04 Oct 2021 02:01:41 PM UTC] Please check log file for more details: /shared/letsencrypt/acme.sh.log
[Mon 04 Oct 2021 02:01:41 PM UTC] Error renew community.thedaily9.in.
[Mon 04 Oct 2021 02:01:41 PM UTC] Renew: 'community.thedaily9.in'
[Mon 04 Oct 2021 02:01:43 PM UTC] Using CA: https://acme.zerossl.com/v2/DV90
[Mon 04 Oct 2021 02:01:43 PM UTC] No EAB credentials found for ZeroSSL, let's get one
[Mon 04 Oct 2021 02:01:43 PM UTC] acme.sh is using ZeroSSL as default CA now.
[Mon 04 Oct 2021 02:01:43 PM UTC] Please update your account with an email address first.
[Mon 04 Oct 2021 02:01:43 PM UTC] acme.sh --register-account -m my@example.com
[Mon 04 Oct 2021 02:01:43 PM UTC] See: https://github.com/acmesh-official/acme.sh/wiki/ZeroSSL.com-CA
[Mon 04 Oct 2021 02:01:43 PM UTC] Please check log file for more details: /shared/letsencrypt/acme.sh.log
[Mon 04 Oct 2021 02:01:43 PM UTC] Error renew community.thedaily9.in_ecc.
[Mon 04 Oct 2021 02:01:43 PM UTC] ===End cron===
root@community-web-only:/# 

Ich denke, dass dieser Commit das Problem löst, und ich wette, dass die Seiten mit diesem Problem vor diesem Commit erstellt wurden.