Gelöst - Caddy startet nicht mehr seit dem letzten Update auf 25.1.10

[Schnuffel2008]

Hallo,

kann mir bitte einmal jemand einen Tipp geben. Ich nutze Caddy als Proxyserver um meine internen Server über https zugänglich zu machen.
Das hat auch immer gut funktioniert. Seit dem letzten Update funktioniert das nicht mehr. Caddy startet einfach nicht mehr.
Hier die Fehlermeldung:
"warn","ts":"2025-07-09T18:22:37Z","logger":"tls","msg":"stapling OCSP","error":"no OCSP stapling for [*****.ipv64.net *.*****.ipv64.net]: no OCSP server specified in certificate"}.
Ich nutze wie man sehen kann ipv64.net und habe mir mit dem ACME-Client mittels DNS-Challenge ein Wildcard-Zertifikat für meine Subdomain erstellt. Das Ganze funktionierte jetzt lange Zeit ohne Probleme. Jetzt tritt dieses Problem auf.
Ich glaube irgendwo etwas gelesen zu haben, dass es eine Änderung mit OCSP gab, weiß aber nicht wo ich etwas Ändern muss. Ich finde auch nicht wo ich einen OCSP-Server eintragen muss, geschweige denn welchen.
Hat jemand eine Idee?

Vielen Dank für Eure Hilfe im voraus.   

[Patrick M. Hausen]

Das ist laut Caddy-Community nur eine Warnung und daher wahrscheinlich nicht die Ursache. Sonst noch was im Log?

Ansonsten könntest du unserem ansässigen Caddy-Guru @Monviech eine private Nachricht mit deiner generierten Config schicken. Oder diese um private Daten bereinigt mal hier posten, natürlich.

[Monviech (Cedrik)]

Mit den so spezialproblemen in Logfiles kenne ich mich nicht ganz so gut aus da ist die Caddy Community der bessere Ort.

Warnungen crashen Caddy aber nicht.

[Schnuffel2008]

Okay,

schon einmal vielen Dank für Eure Hilfe.
Also das was ich oben gepostet hatte stand unter Log/Error,
Das hier steht unter Log/Warning:
2025-07-09T20:22:37   Warning   caddy   "warn","ts":"2025-07-09T18:22:37Z","logger":"admin","msg":"admin endpoint on open interface; host checking disabled","address":"unix//var/run/caddy/caddy.sock|0220"}
Sieht aber auch nicht dramatischer aus, oder?
Na, vielleicht ist ja irgendetwas beim Update wirklich schief gelaufen und es fehlt eine Datei, wenn das Programm nicht mehr startet.
Werde mal alles sichern und bei Gelegenheit neu einspielen (Spätestens beim Update auf 25.7). Dann weiß man mehr.

[Monviech (Cedrik)]

Am besten auch mal kurz ins /var/log/caddy/caddy.log schauen, das loggt fehler beim Starten von Caddy und ist nicht in der GUI zu finden.

[Schnuffel2008]

Das war auf jeden Fall der richtige Tipp.
In der Fehlermeldung steht, dass er das Zertifikat nicht findet:
{"level":"info","ts":1752096208.5293527,"msg":"maxprocs: Leaving GOMAXPROCS=4: CPU quota undefined"}
{"level":"info","ts":1752096208.5294144,"msg":"GOMEMLIMIT is updated","package":"github.com/KimMachineGun/automemlimit/memlimit","GOMEMLIMIT":15207443251,"previous":9223372036854775807}
{"level":"info","ts":1752096208.5294776,"msg":"using config from file","file":"/usr/local/etc/caddy/Caddyfile"}
{"level":"warn","ts":1752096208.5298982,"msg":"No files matching import glob pattern","pattern":"/usr/local/etc/caddy/caddy.d/*.global"}
{"level":"warn","ts":1752096208.5300093,"msg":"No files matching import glob pattern","pattern":"/usr/local/etc/caddy/caddy.d/*.conf"}
{"level":"info","ts":1752096208.534928,"msg":"adapted config to JSON","adapter":"caddyfile"}
{"level":"info","ts":1752096208.5371594,"msg":"redirected default logger","from":"stderr","to":"unixgram//var/run/caddy/log.sock"}
{"level":"info","ts":1752096208.544147,"msg":"maxprocs: No GOMAXPROCS change to reset"}
Error: loading initial config: loading new config: loading http app module: provision http: server srv0: setting up route handlers: route 11: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 1: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 1: loading handler modules: position 0: loading module 'reverse_proxy': provision http.handlers.reverse_proxy: loading transport: loading module 'http': provision http.reverse_proxy.transport.http: making TLS client config: failed to load ca module: loading module 'file': provision tls.ca_pool.source.file: reading /var/db/caddy/data/caddy/certificates/temp/67855b8373165.pem: open /var/db/caddy/data/caddy/certificates/temp/67855b8373165.pem: no such file or directory
Error: caddy process exited with error: exit status 1

Ich verstehe nur leider nicht warum er ein Zertifikat mit dieser Nummer sucht. Da stehen Zertifikate im Ordner aber die Nummer ist eine andere 67441*. Pem und 67441*.key.
Als Automation nach einem Erneuern des Zertifikats habe ich restart caddy eingestellt. Muss man da irgendwie das neu erstellte Zertifikat noch in den caddy/certificates/temp-Ordner Kopieren und wenn ja, wo bekomme ich die aktuelle Nummer des Zertifikats her?

[Patrick M. Hausen]

Geh doch mal in der Caddy-Konfiguration auf die passende Domain, wähl das richtige Zertifikat nochmal aus, und speicher ab.

[Schnuffel2008]

Habe ich jetzt versucht. Das Problem bleibt und wenn ich in den entsprechenden Temp-Ordner gehe stehen da immer noch nur die alten Zertifikate mit der falschen Nummer.

[Monviech (Cedrik)]

Da das modul "transport.http" und "tls.ca_pool" crashed gehe ich von einem CA certificate in einem Handler aus, das hier hinterlegt ist:

https://github.com/opnsense/plugins/blob/fb9748c06d9ae120016e88ed0b8dd1b418d20abe/www/caddy/src/opnsense/mvc/app/controllers/OPNsense/Caddy/forms/dialogHandle.xml#L203

Einfach mal die Zertifikate in diesem Feld abwählen und Apply und schauen ob es wieder startet.

[Schnuffel2008]

Also,
Ich habe das jetzt einmal überprüft. Bei den Handler-Einträgen  TLS Trust Pool hatte ich nur für die OPNsense den E6 Client ausgewählt. Für alle anderen war das Feld auf None.
Wenn ich das für die OPNsense selbst auf None setze und apply drücke kommt umgehend eine rote Dialogbox mit folgender Fehlermeldung:
Error: loading http app module: provision http: server srv0: setting up route handlers: route 11: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 1: loading handler modules: position 0: loading module 'subroute': provision http.handlers.subroute: setting up subroutes: route 1: loading handler modules: position 0: loading module 'reverse_proxy': provision http.handlers.reverse_proxy: loading transport: loading module 'http': provision http.reverse_proxy.transport.http: making TLS client config: failed to load ca module: loading module 'file': provision tls.ca_pool.source.file: reading /var/db/caddy/data/caddy/certificates/temp/67855b8373165.pem: open /var/db/caddy/data/caddy/certificates/temp/67855b8373165.pem: no such file or directory

[Monviech (Cedrik)]

Versuche irgend ein anderes Zertifikat in dem Feld auszuwählen.

Ich denke der ACME Client hat das E6 Zertifikat ausgetauscht und es existiert nicht mehr.

Das ist etwas blöd aber kann ich programmatisch nichts dran ändern wenn ein Zertifikat einfach automatisch aus dem Modell entfernt wird.

Falls ein anderes Zertifikat auch nicht geht kann es sein dass du in einem Bug gefangen bist. Das muss ich mir dann mal anschauen da ich jetzt ungefähr weis wie man es triggern könnte.

Du kannst die OPNsense Configuration exportieren und dort Manuell das Zertifikat aus der Caddy configuration entfernen indem du einfach das Feld leermachst in dem es steht. Danach Konfig importieren.

[Schnuffel2008]

Also ich habe anstatt des E6 clients im Handler den E5 client ausgewählt. Das brachte keine Änderung. Ich hoffe Du meinst das.
Und jetzt nur für mich zum Verständnis. Ich soll dieses Feld leeren nach dem Export und neu importieren oder das Zertifikat im Feld certificate von der Domain löschen und dann neu importieren?

[Monviech (Cedrik)]

Du lädst die Configuration in "System - Configuration - Backup" herunter.

Dann öffnest du sie mit z.b. Notepad und suchst so eine stelle

<caddy version="1.3.7">

Dann gehst du z.b. zu allen handler die so aussehen:

Code Select Expand

        <handle uuid="c5d1ecf6-b678-4bd8-a516-c210e80c3350">
          <enabled>1</enabled>
          <reverse>e40998d9-94cf-4ca5-85df-1d7479acf375</reverse>
          <subdomain/>
          <HandleType>handle</HandleType>
          <HandlePath/>
          <accesslist/>
          <basicauth/>
          <header/>
          <HandleDirective>reverse_proxy</HandleDirective>
          <ToDomain>127.0.0.1</ToDomain>
          <ToPort>4444</ToPort>
          <ToPath/>
          <ForwardAuth>0</ForwardAuth>
          <HttpTls>1</HttpTls>
          <HttpVersion/>
          <HttpKeepalive/>
          <HttpNtlm>0</HttpNtlm>
          <HttpTlsInsecureSkipVerify>0</HttpTlsInsecureSkipVerify>
          <HttpTlsTrustedCaCerts>653e13f7a6995</HttpTlsTrustedCaCerts>
          <HttpTlsServerName/>
          <lb_policy/>
          <lb_retries/>
          <lb_try_duration/>
          <lb_try_interval/>
          <PassiveHealthFailDuration/>
          <PassiveHealthMaxFails/>
          <PassiveHealthUnhealthyStatus/>
          <PassiveHealthUnhealthyLatency/>
          <PassiveHealthUnhealthyRequestCount/>
          <description>vpn1.akiru.org</description>
          <health_uri/>
          <health_upstream/>
          <health_port/>
          <health_interval/>
          <health_passes/>
          <health_fails/>
          <health_timeout/>
          <health_status/>
          <health_body/>
          <health_follow_redirects>0</health_follow_redirects>
        </handle>
Überall wo du

Code Select Expand

<HttpTlsTrustedCaCerts>653e13f7a6995</HttpTlsTrustedCaCerts> siehst, einfach

Code Select Expand

<HttpTlsTrustedCaCerts/> machen <---- beachte dass es mit /> abschließt.

Wenn du die Zertifikatsnummer noch an anderen Stellen in der Caddy Configuration findest, auch so entfernen.

Wenn du überall diese Zertifikatreferenz in der Caddy Konfiguration entfernt hast, die Konfiguration in "System - Configuration - Backup" importieren und bei Caddy apply drücken.

Wenn es jetzt immer noch nicht geht obwohl alle Referenzen weg sind, dann noch:

Code Select Expand

cd /usr/local/etc/caddy/
rm Caddyfile

configctl caddy restart
Wenn dann immer noch nicht, plugin deinstallieren und nochmal installieren.

Wenn dann immer noch nicht, keine Ahnung gerade. :)

[Schnuffel2008]

Hallo,

ich habe das Problem gelöst. Es war natürlich sicher meine Dummheit.
Ich habe so ziemlich alle Zugänge zu den Switches zum Ubi-Netzwerkcontroller zu Proxmox etc. mit Caddy als Reverse-Proxy so eingerichtet, dass ich dieses nervige "Nicht sicher" mit durchgestrichenem https im Browser loswerde indem ich den Namen plus Domain aufrufe.
Das ganze habe ich auch für die Admin-Weboberfläche des CUPS-Servers versucht. Und das funktioniert nicht und bringt die Fehlermeldung, dass Caddy nicht startet. Ich war eigentlich der festen Überzeugung, dass das früher einmal so ging, aber vielleicht täusche ich mich auch. Ich habe jedenfalls den entsprechenden Eintrag gelöscht und alles funktioniert wieder.
Sorry für die Arbeit, die ich gemacht habe und vielen Dank für Eure Hilfe.

[Monviech (Cedrik)]

Mich interessiert genau welches Zertifikat du auswählst. Kannst du mir einen Screenshot in der GUI zeigen, von "Trust - Authorities" wo man das Zertifikat sehen kann dass du benutzt?

Kannst du genau dieses Zertifikat in der Konfigurationsdatei suchen ob es dort auch existiert?

Ich hab eine Vermutung will es aber wissen.