Reeve Sicherheitsgrundlagen
Zertifikat nicht vertrauenswürdig: drei Ursachen außer Ablauf
Zertifikat nicht vertrauenswürdig, obwohl das Datum stimmt? Es nennt eine andere Adresse, hat sich selbst signiert oder seiner Kette fehlt ein Glied.
Kurz gesagt
- Ein Zertifikat, dem Browser nicht vertrauen, kann völlig gültig datiert sein. Abgelehnt wird es, weil es eine andere Adresse nennt, weil es sich selbst signiert hat oder weil es ohne das Zertifikat ankam, das für es bürgt.
- Der Warnbildschirm ist derselbe wie bei einem abgelaufenen Zertifikat, und Verlängern behebt keine der drei Ursachen. Der Code unter der Warnung sagt dir, welche du hast.
- Bei Lovable und Vercel zeigt eine eigene Domain diese Warnung, bis ihr Zertifikat ausgestellt ist. Diese Wartezeit ist normal. Eine Warnung, die länger bleibt, heißt, dass etwas das Zertifikat aufhält.
Deine App hat gestern problemlos geladen. Heute schickt dir jemand einen Screenshot einer ganzseitigen Browserwarnung, die Verbindung sei nicht privat, und fragt, ob deine Seite gehackt wurde. Du öffnest das Zertifikat, und es ist bis zum nächsten Frühling gültig. Abgelaufen ist es also nicht, und der Browser sagt trotzdem, dem Zertifikat sei nicht zu vertrauen.
Der naheliegende Schritt ist, es zu verlängern, und bei diesem Bildschirm ist es der falsche. Jede der drei Ursachen unten trifft ein Zertifikat, das bereits gültig datiert ist. Eine Verlängerung bringt dir also ein späteres Ablaufdatum auf einem Zertifikat, das aus einem anderen Grund weiter abgelehnt wird.
In unserem Beitrag über den Ablauf ist das Zertifikat die Zulassung im Fenster, die sagt, dass dieser Laden wirklich der auf dem Schild ist. Der Browser eines Besuchers liest auf dieser Zulassung drei Dinge, bevor er jemanden hereinlässt: das Datum, den Namen des Ladens, für den sie ausgestellt wurde, und die Unterschrift dessen, der sie ausgestellt hat. Der Ablauf ist das Datum. In diesem Artikel geht es um die anderen beiden.
Warum ist mein Zertifikat nicht vertrauenswürdig, obwohl es nicht abgelaufen ist?
Weil der Name oder die Unterschrift durchgefallen ist, und der Browser stellt bei jeder seiner Prüfungen dieselbe Wand auf.
Einem Zertifikat wird nur vertraut, wenn es genau die Adresse in der Adressleiste des Besuchers nennt und von einer Stelle signiert wurde, der der Browser schon vertraut, mit jedem Zertifikat dazwischen im Gepäck. Fällt eins davon durch, zeigt Chrome die Warnung, dass die Verbindung nicht privat ist, und Firefox die Warnung vor einem möglichen Sicherheitsrisiko, genau wie bei einem abgelaufenen Zertifikat.
Was sich unterscheidet, ist das Kleingedruckte unter der Warnung. Lies es, bevor du irgendetwas änderst:
| Was Chrome anzeigt | Was die Erklärung in Firefox sagt | Was es bedeutet | Was es behebt |
|---|---|---|---|
NET::ERR_CERT_COMMON_NAME_INVALID | Das Zertifikat ist für deine Adresse nicht gültig | Es wurde für einen anderen Namen ausgestellt | Ein Zertifikat, das genau deine Adresse führt |
NET::ERR_CERT_AUTHORITY_INVALID | Dem Zertifikat wird nicht vertraut, weil es selbstsigniert ist | Niemand bürgt dafür außer dem Server selbst | Ein Zertifikat von einer echten Zertifizierungsstelle |
NET::ERR_CERT_AUTHORITY_INVALID | Der Aussteller des Zertifikats ist unbekannt | Der Browser kann es mit keiner Stelle verbinden, der er vertraut | Die vollständige Kette, von einer anerkannten Stelle |
NET::ERR_CERT_DATE_INVALID | Das Zertifikat ist abgelaufen | Das Datum | Ein neues Zertifikat |
Chrome zeigt für die zweite und dritte Zeile denselben Code, deshalb lohnt es sich, das Zertifikat selbst zu öffnen.
Wenn eine Person die Warnung meldet und sonst niemand sie sieht, frag, in welchem Netz sie war. Der Quellcode von Chrome nennt ein WLAN, das seine Nutzer auf eine Anmeldeseite umleitet, als eine Ursache des Namensfehlers. Die verschwindet, sobald sie sich im Netz anmeldet.
Wie sehe ich, was im Zertifikat steht?
Öffne es aus der Warnung heraus und lies zwei Felder: für wen es ausgestellt wurde und wer es ausgestellt hat.
In Chrome klickst du auf den Warnhinweis links in der Adressleiste (Not secure in einem englischen Chrome) und öffnest das Zertifikat aus dem Fenster, das erscheint. In Firefox klickst du in der Warnung auf Advanced und dann auf den Link zum Zertifikat der Website (so heißen sie in einem englischen Firefox). Die beiden Browser benennen dieselben Felder unterschiedlich:
- Das Feld, für wen das Zertifikat ausgestellt wurde (Issued To in einem englischen Chrome, Subject Name in Firefox), nennt den Namen, für den es gemacht wurde. Die vollständige Liste der Namen, die es abdeckt, steht unter Subject Alternative Name, und diese Liste vergleicht der Browser mit der Adresse.
- Das Feld, wer es ausgestellt hat (Issued By in Chrome, Issuer Name in Firefox), nennt die Stelle, die es signiert hat.
Jede der drei Ursachen liest sich dort anders:
- Das Zertifikat nennt eine andere Adresse. Das ist Ursache 1.
- Inhaber und Aussteller tragen denselben Namen. Es hat sich selbst signiert, das ist Ursache 2.
- Es nennt deine Adresse, der Aussteller ist eine Stelle, von der du gehört hast, und der Browser lehnt es trotzdem ab. Das ist Ursache 3, die Kette.
Ursache 1: Das Zertifikat gilt für eine andere Adresse
Das Zertifikat ist echt und gültig datiert, und es wurde für einen anderen Namen ausgestellt. Es ist die Zulassung eines anderen Ladens, die in deinem Fenster hängt.
Es kommt in drei Formen vor:
- Deine Domain zeigt auf einen Host, der noch kein Zertifikat für sie hat. Der Host antwortet mit dem Zertifikat, das er hat, ausgestellt auf einen eigenen Namen. Lovables Dokumentation sagt es klar: Bis das Zertifikat bereit ist, zeigt der Browser statt deiner Seite eine Sicherheitswarnung.
- Das Zertifikat deckt eine Schreibweise deiner Adresse ab, und der Besucher
hat die andere getippt.
www.yourapp.comundyourapp.comsind für ein Zertifikat zwei Namen, und jeder muss auf seiner Liste stehen. - Ein Teil deines DNS zeigt noch auf einen Ort, den du verlassen hast. Ein alter Host oder die Parkseite, die dein Registrar zeigte, bevor du etwas verbunden hast, antwortet auf diesem Namen mit einem eigenen Zertifikat.
Bei Lovable und Vercel kaufst und installierst du dieses Zertifikat nicht selbst. Der Host stellt eines für jeden Namen aus, den du in seinen Domain-Einstellungen hinzufügst, sobald dein DNS diesen Namen auf den Host richtet. Lovables Dokumentation ergänzt, dass ein bei deinem Registrar gekauftes Zertifikat von seinem Hosting überhaupt nicht verwendet wird. Füge beide Schreibweisen hinzu, richte beide auf den Host und warte, bis jede als live angezeigt wird.
Ursache 2: Das Zertifikat hat sich selbst signiert
Niemand bürgt für dieses Zertifikat außer dem Server, der es vorzeigt. Es ist eine Zulassung, die der Ladenbesitzer zu Hause gedruckt hat.
Jeder Browser lehnt so eines auf einer öffentlichen Seite ab, und das soll er auch. Ein Kommentar im Quellcode von Chrome nennt den Grund in einer Zeile: Ein selbstsigniertes Zertifikat bietet keinen Schutz gegen einen Angreifer, der zwischen deinem Besucher und deiner App sitzt.
Du triffst es auf Servern, die jemand von Hand eingerichtet hat: ein gemieteter Server, ein selbst gehostetes Tool, eine Testeinstellung, die mit der App live gegangen ist. Ein Builder stellt echte Zertifikate für die Domains aus, die du bei ihm hinzufügst. Ein selbstsigniertes Zertifikat auf einer App, die ein Builder hostet, heißt also, dass etwas anderes als der Builder auf deiner Adresse antwortet. Prüf, wohin dein DNS zeigt, bevor du irgendetwas anderes änderst.
Die Lösung ist ein Zertifikat von einer echten Zertifizierungsstelle. Let's Encrypt stellt sie kostenlos aus, und es ist die Stelle, die Vercel nutzt, wenn es deines ausstellt.
Ursache 3: Ein Glied der Kette wurde nie mitgeschickt
Das Zertifikat gilt für deine Adresse und wurde von einer echten Stelle signiert, aber der Server hat es ohne das Zertifikat dazwischen geschickt, also kann der Browser es mit niemandem verbinden, dem er vertraut. Die Zulassung hat eine Zweigstelle unterschrieben, und das Schreiben der Zentrale, das für diese Zweigstelle bürgt, fehlt im Fenster.
Mozilla nennt ein fehlendes Zwischenzertifikat eines der häufigsten Probleme bei der Serverkonfiguration. Firefox lädt inzwischen vorab eine Kopie jedes vertrauenswürdigen Zwischenzertifikats herunter, damit seine Nutzer dem Fehler nicht mehr begegnen.
Das macht diese Ursache schwer zu sehen: Auf deinem Laptop kann alles gut aussehen, während es bei jemand anderem scheitert. Ein Browser mit einer eigenen Kopie des fehlenden Glieds füllt die Lücke. Software, die nur das verwendet, was dein Server schickt, hat nichts, womit sie sie füllen könnte. Unser Scanner ist so eine Software, und deshalb kann er ein Zertifikat als nicht vertrauenswürdig melden, während dein eigener Browser ein Schloss zeigt.
Bei einem Builder wird die Kette für dich erledigt. Sie fehlt auf Servern, die
von Hand konfiguriert wurden, und die Lösung dort ist, das Zertifikat zusammen
mit dem Zwischenzertifikat in einer Datei auszuliefern. Wenn du certbot von
Let's Encrypt verwendest, ist das die Datei fullchain.pem, und der Fehler
besteht darin, den Server stattdessen auf cert.pem zu richten. Zum Prüfen von
außen meldet der kostenlose Servertest von SSL Labs
ein fehlendes Zwischenzertifikat als Problem der Kette.
Der Fall mit der eigenen Domain, der Reihe nach
Wenn du deine eigene Domain mit einem Builder verbindest, sehen Besucher diese Warnung, bis der Host ein Zertifikat für deinen Namen hat, und die Warnung sagt die Wahrheit. Sie endet von selbst, sobald das Zertifikat ausgestellt ist.
Die Reihenfolge bei Lovable:
- Füge die Domain in Lovable hinzu. Es richtet
yourapp.comundwww.yourapp.comein und führt sie getrennt auf. - Ändere die DNS-Einträge bei deinem Registrar auf die Werte, die Lovable dir gibt. Laut Lovable sind die meisten Änderungen innerhalb weniger Stunden aktiv, und die Verbreitung kann bis zu 72 Stunden dauern.
- Lovable prüft die Domain und stellt das Zertifikat aus. Vercel arbeitet genauso: Es weist Let's Encrypt automatisch nach, dass der Name dir gehört, solange die Domain auf Vercel zeigt.
- Öffne die Seite, sobald die Domain als Live angezeigt wird. Das rät Lovable selbst.
Wenn die Warnung nach 72 Stunden noch da ist, bittet Lovable dich, seinen Support zu kontaktieren. Zwei Einstellungen solltest du vorher prüfen:
- Such nach einem CAA-Eintrag. Das ist ein DNS-Eintrag, der festlegt, welche Stellen Zertifikate für deine Domain ausstellen dürfen. Einer, der die Stelle deines Hosts auslässt, blockiert das Zertifikat, und eine Subdomain übernimmt die CAA-Einträge der übergeordneten Domain, wenn sie keine eigenen hat. Der Beitrag über den Ablauf begegnet demselben Eintrag als Grund, warum eine Verlängerung scheitert. Hier verhindert er, dass das erste Zertifikat überhaupt ausgestellt wird.
- Such nach einem Proxy davor. Liegt dein DNS bei Cloudflare und ist die orange Wolke für die Einträge eingeschaltet, die dein Host dir gegeben hat, antwortet Cloudflare statt deines Hosts. Lovable sagt, dass es die Domain dann nicht prüfen und keine Zertifikate für sie ausstellen kann, und Lovable wie Vercel sagen, diese Einträge auf DNS only zu stellen.
Was wir bei 30.879 Apps gefunden haben
Acht hatten ein Zertifikat, dem kein Browser vertrauen würde, und jede davon lief auf einer Domain, die ihr Besitzer verbunden hatte.
Im August 2026 hat unser Scan das Zertifikat von 30.879 Live-Apps gelesen: 29.927 auf der eigenen Subdomain eines Builders und 952 auf einer eigenen Domain. Alle acht nicht vertrauenswürdigen Zertifikate waren unter den 952, knapp eines von hundert. Keine der Apps auf der Subdomain eines Builders hatte eines, was zu allem oben passt. Auf der eigenen Adresse des Builders gehören dem Builder sowohl der Name als auch das Zertifikat.
Unser Befund hält fest, dass das Zertifikat durchgefallen ist, aber nicht, welche der drei Ursachen es war, also können wir dir nicht sagen, wie sich die acht aufteilen. Die abgelaufenen und bald ablaufenden Zertifikate aus demselben Scan sind im Beitrag über den Ablauf gezählt.
Um deine eigene App zu prüfen, liest unser kostenloser Scan das Zertifikat, das dein Server schickt, von außen und nennt diesen Befund, wenn er ihn sieht. Das dauert etwa 20 Sekunden und braucht kein Konto.
Es mitbekommen, wenn sich das nächste Mal etwas ändert
Ein Zertifikat wird von vertrauenswürdig zu abgelehnt, wenn sich etwas um es herum ändert: eine neue Domain, ein DNS-Umzug, ein eingeschalteter Proxy. Die Prüfung, auf die es ankommt, ist die nach der Änderung.
Scanne deine App kostenlos, um zu sehen, was der Browser eines Besuchers heute bekommt.
- Liest das Zertifikat, das dein Server schickt, von außen, zusammen mit acht weiteren Prüfungen.
- Nennt den Befund, wenn dem Zertifikat nicht vertraut wird, und wenn es abgelaufen ist oder bald abläuft.
- Etwa 20 Sekunden, und kein Konto.
Reeve Monitor, um es bald nach der Änderung zu erfahren.
- Prüft deine App alle 60 Sekunden, und ein Zertifikat, dem es nicht vertrauen kann, zählt als Ausfall deiner App. Du erfährst es also wie bei jedem anderen Ausfall.
- Führt alle neun Prüfungen jede Stunde erneut aus und schickt dir eine E-Mail, wenn deine Note sinkt.
- Deckt bis zu drei Apps ab.
Was du jetzt tun solltest
Was zu tun ist
- Lies den Code unter der Warnung, bevor du irgendetwas verlängerst. Ein Datumsfehler braucht ein neues Zertifikat. Ein Namens- oder Ausstellerfehler braucht etwas anderes.
- Öffne das Zertifikat und vergleiche den Namen, für den es ausgestellt wurde, mit der Adresse in der Leiste und mit dem Namen dessen, der es ausgestellt hat.
- Bei einem Builder fügst du
yourapp.comundwww.yourapp.comin seinen Domain-Einstellungen hinzu und richtest beide auf ihn. - Zeigt eine neue Domain nach 72 Stunden noch die Warnung, such nach einem CAA-Eintrag oder einem Proxy vor dem Host, bevor du den Support kontaktierst.
- Auf einem Server, den du selbst betreibst, liefere die vollständige Kette aus und prüf sie von außen mit SSL Labs.
Wenn die Warnung weg ist und die App trotzdem nicht lädt, ist die nächste Frage, ob es an deiner App liegt oder an der Plattform darunter, und ist Supabase ausgefallen oder deine App zeigt, wie du das unterscheidest.
FAQ
Warum sagt meine Website „nicht privat", obwohl mein Zertifikat nicht abgelaufen ist?
Weil das Datum nur eine von drei Prüfungen ist, die ein Browser macht, und die anderen beiden für sich allein scheitern. Das Zertifikat muss außerdem genau die Adresse nennen, die der Besucher eingetippt hat, und von einer Stelle signiert sein, der der Browser vertraut, wobei jedes Zertifikat dazwischen mitgeschickt wird. Scheitert eine der beiden Prüfungen, kommt dieselbe ganzseitige Warnung wie bei einem abgelaufenen Zertifikat, und Verlängern ändert nichts.
Was ist ein Namenskonflikt beim Zertifikat?
Ein Zertifikat, das für eine Adresse ausgestellt wurde und auf einer anderen vorgezeigt wird. Chrome meldet es als NET::ERR_CERT_COMMON_NAME_INVALID, Firefox sagt, das Zertifikat sei für deine Adresse nicht gültig. Das Zertifikat selbst ist meist echt und gültig datiert. Es gehört nur zu einem anderen Namen, oft dem deines Hosts, und genau damit antwortet ein Host auf deiner Domain, bevor er eines für dich ausgestellt hat.
Warum funktioniert www und die Domain ohne www nicht?
Weil das für ein Zertifikat zwei verschiedene Namen sind. Entweder führt das Zertifikat nur einen davon, oder das DNS des anderen zeigt noch woandershin, etwa auf die Parkseite deines Registrars oder einen alten Host, der mit einem eigenen Zertifikat antwortet. Lovable verbindet beide und führt sie getrennt auf, also prüf, ob jede als live angezeigt wird.
Wie lange dauert ein Zertifikat für eine eigene Domain?
Laut Lovable ist die Einrichtung einer Domain meist in wenigen Minuten fertig, kann aber bis zu mehreren Stunden dauern. DNS-Änderungen können bis zu 72 Stunden brauchen, bis sie sich verbreitet haben, und wenn das Zertifikat nach 72 Stunden nicht ausgestellt ist, sollst du den Support kontaktieren. Bis es ausgestellt ist, sehen Besucher statt deiner Seite eine Sicherheitswarnung.
Ist ein selbstsigniertes Zertifikat jemals in Ordnung?
Auf deinem eigenen Rechner, zum Entwickeln, ja. Auf einer Seite, die die Öffentlichkeit besucht, nein. Jeder Browser deiner Besucher lehnt es ab, und ein Kommentar im Quellcode von Chrome hält fest, dass ein selbstsigniertes Zertifikat keinen Schutz gegen einen Angreifer bietet, der zwischen Besucher und Seite sitzt.