n8n und Supabase: Zertifikatskette wird abgelehnt?

n8n kann deine Supabase-Postgres-Datenbank nicht verbinden und meldet self-signed certificate in certificate chain. Mit ausgeschalteter Zertifikatsprüfung scheint es zu funktionieren. Das grenzt das Problem ein, liefert aber noch keine dauerhaft geeignete Konfiguration für vertrauliche Daten.

Was belegt ist und was offen bleibt

Ein öffentlicher Bericht schildert dieses Verhalten bei n8n Cloud. Dort fehlte dem Nutzer eine Eingabe für eine eigene CA-Datei. Q1 Die Postgres-Credential-Dokumentation unterscheidet SSL-Einstellungen und die Option, Zertifikatsfehler zu ignorieren. Für selbst betriebene n8n-Instanzen dokumentiert n8n zusätzlich eigene CA-Zertifikate. Q2 Q3 Daraus folgt nicht, dass jeder Cloudtarif denselben Importweg bietet.

Die Fehlermeldung beweist auch nicht, dass die Datenbank absichtlich ein unsicheres Zertifikat verwendet. Möglich sind beispielsweise eine unvollständige Kette, ein abweichender Endpunkt oder fehlendes Vertrauen in eine beteiligte Zertifizierungsstelle. Diese Möglichkeiten müssen getrennt geprüft werden.

Prüfschritte mit klarer Entscheidung

1. Endpunkt identifizieren. Vergleiche Hostname, Port, Verbindungsmodus und Datenbankbenutzer mit den tatsächlich für dein Projekt bereitgestellten Angaben. Direkte Verbindung und Pooler sind unterschiedliche Ziele; ein Portwechsel installiert keine fehlende Vertrauenskette.
2. Fehler exakt sichern. Notiere n8n-Version, Cloud oder Container und die SSL-Auswahl. Zeige keine Passwörter oder vollständigen Connection-Strings in öffentlichen Screenshots.
3. Kette für diesen Host prüfen lassen. Der Datenbankbetreiber beziehungsweise Administrator vergleicht Aussteller, Zwischenzertifikate, Gültigkeit und Hostnamenbezug. Ein Test mit einer anderen Datenbankadresse lässt keine Aussage über den ursprünglichen Host zu.
4. Cloud-Fähigkeit klären. Frage bei fehlender CA-Einstellung den n8n-Support nach dem unterstützten Weg für genau diese Datenbankverbindung. Die Anleitung für einen Container ist keine im Cloudkonto verfügbare Funktion.
5. Bei Eigenbetrieb gezielt Vertrauen ergänzen. Nutze nur das verifizierte öffentliche CA-Zertifikat aus vertrauenswürdiger Quelle und den dokumentierten Mechanismus deiner n8n-Version. Anschließend Verbindung mit aktiver Prüfung testen. Private Schlüssel gehören nicht in den CA-Ordner.

Wann die Reparatur ausreichend geprüft ist

Ein grüner Verbindungstest reicht als Funktionstest. Zusätzlich muss klar sein, dass die gewünschte Zertifikats- und Hostnamenprüfung tatsächlich aktiv ist. „Verschlüsselt“ und „Identität korrekt geprüft“ sind unterschiedliche Anforderungen. Halte die unterstützte Konfiguration und ihre Zuständigkeit fest, damit ein Containerwechsel die Lösung nicht unbemerkt entfernt.

Häufige Fragen

Kann „Ignore SSL issues“ dauerhaft eingeschaltet bleiben?

Damit wird die beanstandete Prüfung umgangen. Behandle das nicht als Beleg einer verifizierten Verbindung; kläre stattdessen die Vertrauenskette.

Was muss ich für Hilfe vorbereiten?

Produktversionen, Hostingart, anonymisierten Endpunkttyp, Fehlertext und die verwendete SSL-Konfiguration. CA-Aussteller und Ablaufdatum helfen; Zugangsdaten brauchst du dafür nicht zu veröffentlichen.

Unterstützung für diesen Fall

Wir helfen dir, den betroffenen Ablauf einzugrenzen und die nächste Maßnahme kontrolliert vorzubereiten. Fall A0065 mit KAN KAI WORKS besprechen.