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.
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.
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.
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.
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.
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?
Geh doch mal in der Caddy-Konfiguration auf die passende Domain, wähl das richtige Zertifikat nochmal aus, und speicher ab.
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.
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.
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
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.
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?
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:
<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
<HttpTlsTrustedCaCerts>653e13f7a6995</HttpTlsTrustedCaCerts> siehst, einfach
<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:
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. :)
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.
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.
Also,
so steht das Zertifikat im Caddyfile:
{
tls /var/db/caddy/data/caddy/certificates/temp/677413917419a.pem /var/db/caddy/data/caddy/certificates/temp/677413917419a.key {
}
Und diese Dateien stehen nun auch im entsprechenden Ordner.
Vorher hat das wie gesagt nicht gepasst.
Auf dem Bild ist angehangen wie es in der GUI aussieht.
Sieht eigendlich ok aus.
Was ich mir vorstellen kann ist dass diese Zertifikate automatisch gelöscht und neu angelegt wurden mit einer anderen Nummer.
Wenn dabei nicht geprüft wird ob das Zertifikat im Modell z.B an einer anderen Stelle genutzt wird, dann wird es falsche Referenzen in der Configuration geben und es kommt zu sowas in Caddy passiert ist.
Nächstes Mal Frage ich gleich nach der Caddy Validate Taste die es in Diagnostics gibt, hab vergessen dass ws die gibt xD
Ich kann denke ich kann aber nicht verhindern dass dies passieren kann.
Die Modularität des Plugin Systems hat vor und Nachteile.
Danke und schönen Abend. :)
Frage: warum ist das CA-Zertifikat in Caddy überhaupt konfiguriert? Wenn der Handler ein Backend-System kontaktiert, das man selbst kontrolliert, dann ist doch schnurz, von welcher CA das Zertifikat ist.
Ich fahre die Mehrheit meiner Anwendungen, die eingehend durch Caddy laufen, sogar ganz absichtlich ohne jede Verschlüsselung. Das macht ja der Caddy. Und wenn ich mal was debuggen muss, hab ich Klartext. Und in einem switched Netz, in dem die OPNsense mit Caddy und alle anderen Systeme in derselben Layer-2-Infrastruktur hängen, kann da auch niemand mitschnüffeln, es sein, es hackt den Switch.
Just sayin' :-)
QuoteFrage: warum ist das CA-Zertifikat in Caddy überhaupt konfiguriert? Wenn der Handler ein Backend-System kontaktiert, das man selbst kontrolliert, dann ist doch schnurz, von welcher CA das Zertifikat ist.
Ich kenne mich leider zu wenig aus. Verstehe ich Deine Frage richtig, dass ich meine ganzen Geräte/Server auch ohne das ACME-Zertifikat über https und ohne Fehlermeldung mittels Caddy ansprechen kann. Wie müsste ich das konfigurieren?
Und wenn hier schon die Profis unterwegs sind, dann gleich noch ne Frage. Let's encrypt unterstützt ja jetzt auch ip-zertifikate. Könnte man damit auch endlich alle seine server direkt über die ip-Adresse mittels https aufrufen (also zB https://192.168.1.1) oder funktioniert das nur für die öffentliche Adresse und wie funktioniert das.
Du musst zwischen der externen Kommunikation und dem Backend Caddy --> realer Server unterscheiden. Natürlich willst du extern alles, was auf Caddy terminiert, mit SSL versorgen. Das macht der ja auch ganz prima.
Aber im Backend zwischen Caddy und dem Server brauchst du SSL eigentlich nicht. Und wenn es "nunmal da" ist, dann kannst du in Caddy m.E. auch darauf verzichten, die CA zu überprüfen, oder überhaupt, ob das Zertifikat öffentlich gültig ist. Dafür gibt es ja eine Checkbox, hab die Bezeichnung gerade nicht im Kopf.
Wenn ich dein Problem richtig verstanden habe, startet Caddy nicht wegen eines in einem Handler konfigurierten CA-Zertifikats. Wenn das stimmt, dann war meine erste Frage gerade eben: weshalb ist das überhaupt so konfiguriert?
Okay,
wie gesagt ich bin ja nur Laie und da sucht man sich für solche doch schon etwas komplizierten Themen halt Hilfe im Forum in den Amleitungen und nauch sonst was man noch finden kann.
Ich hatte als erstes den Handler für die OPNsense selbst erstellt und ich glaube irgendwo gelesen zu haben, dass dort die Konfiguration mit dem Zertifikat angegeben war. Aber Du hast Recht, wenn ich den E6-Client bei TLS Trust Pool rausnimmt, dann geht es genauso ohne Probleme.
Ist ja gut zu wissen und ich habe wieder etwas gelernt.
Aber eine Möglichkeit die IP-Nummern über https ohne Warnmeldung im Browser zu erreichen gibt es wohl nicht, oder?