# TLS-Zertifikatsfehler: Verfahren für die Reaktion eines Agenten

Ein Zertifikatsfehler bei einem Agent-API-Aufruf ist ein Stoppsignal und keine kleine Netzwerkstörung. Der Aufruf kann ein Bearer-Token, eine signierte Anfrage, einen Kundendatensatz oder Anweisungen enthalten, die den Produktionszustand ändern. Wenn der Client nicht feststellen kann, wem die andere Seite der Verbindung gehört, darf er nichts davon senden.

Solche Fehler werden häufig falsch behandelt, weil jemand unter Zeitdruck ein abgelaufenes Zertifikat sieht und zu einer unsicheren Option greift. Bei einem autonomen Agenten verschärft sich das Problem. Er kann schnell erneut versuchen, einer versteckten Anweisung in einem Repository-Issue folgen und denselben unsicheren Aufruf mit mehreren Zugangsdaten wiederholen. Ein gutes Verfahren stoppt den Lauf, trennt Fakten von Vermutungen und stellt den Zugriff erst wieder her, wenn jemand nachgewiesen hat, dass der erwartete Endpunkt wieder der Endpunkt ist, der den Datenverkehr empfängt.

## Eine Zertifikatswarnung ändert die Vertrauensentscheidung

TLS erfüllt zwei Aufgaben, die oft vermischt werden. Es verschlüsselt den Datenverkehr und prüft die Identität des Servers. Verschlüsselung ohne Identitätsprüfung gibt einem Angreifer lediglich eine private Unterhaltung mit deinem Client.

RFC 6125 beschreibt, wie eine Anwendung die Identität eines Dienstes mit einer Referenzkennung abgleicht, meist dem DNS-Namen, den der Client erreichen wollte. RFC 5280 beschreibt die Prüfung des Zertifikatspfads: Der Client bildet eine Kette vom präsentierten Leaf-Zertifikat über Zwischenzertifikate bis zu einem Vertrauensanker. Beide Prüfungen sind wichtig. Ein Zertifikat kann eine gültige Signatur haben und trotzdem zu `api-attacker.example` statt zu `api.example` gehören. Es kann den richtigen Hostnamen enthalten und trotzdem auf einen Aussteller zurückgehen, den deine Organisation nie freigegeben hat.

Bei Agent-Datenverkehr sind die Folgen konkret. Ein in eine HTTPS-Anfrage eingefügtes Bearer-Token kann von jedem verwendet werden, der die Verbindung beendet. Eine mit einer Client-Zugangsdaten signierte Anfrage kann Zustandsänderungen autorisieren. Die Antwort eines Betrügers kann eine spätere Aktion anweisen oder den Arbeitskontext des Agenten verfälschen. Dass die Anfrage verschlüsselt war, ändert daran nichts.

Behandle diese Meldungen als sicherheitsrelevant, bis ihre Ursache geklärt ist:

- Zertifikat abgelaufen oder noch nicht gültig
- Hostname oder Subject Alternative Name stimmt nicht überein
- lokales Ausstellerzertifikat fehlt oder erstes Zertifikat konnte nicht geprüft werden
- selbstsigniertes Zertifikat in der Zertifikatskette
- Zertifikatsprüfung nach einer Proxy-, DNS- oder Netzwerkänderung fehlgeschlagen

Nicht jeder Fehler ist ein aktiver Angriff. Ein vergessenes Zwischenzertifikat und eine falsch eingestellte Laptop-Uhr sind gewöhnliche Betriebsfehler. Die Untersuchung beginnt trotzdem mit Unsicherheit, weil dieselbe Fehlerklasse auch entsteht, wenn jemand Datenverkehr umleitet oder einen nicht freigegebenen Abfangproxy installiert.

Eine erfolgreiche TCP-Verbindung beweist nur, dass etwas an einer Adresse geantwortet hat. Ein erfolgreicher TLS-Handshake mit deaktivierter Prüfung beweist noch weniger. Die Serveridentitätsprüfung entscheidet, ob ein API-Aufruf mit Zugangsdaten den Rechner verlassen darf.

## Den betroffenen Lauf stoppen, bevor du Hinweise sammelst

Die erste operative Maßnahme besteht darin, weitere authentifizierte Aufrufe an das fehlerhafte Ziel zu verhindern. Pausiere den Agent-Prozess, widerrufe seine aktive Sitzung, wenn deine Aktionsschicht das unterstützt, oder entziehe ihm die Berechtigung für diese Aktion. Tu das, bevor du eine Stunde darüber diskutierst, ob dir das Zertifikat bekannt vorkommt.

Bewahre den ursprünglichen Fehler unverändert auf. Notiere den vollständigen Hostnamen und Port, die Anfragemethode ohne Authorization-Header, den Zeitstempel mit Zeitzone, Laufzeitumgebung und Version des Clients sowie den Prozess, der den Aufruf gestartet hat. Halte fest, welches Netzwerk der Rechner verwendet hat und ob der Fehler nach einem Deployment, einer Zertifikatserneuerung, einer VPN- oder Proxy-Änderung, einem DNS-Update oder einer Änderung der Geräteverwaltung begann.

Bewahre diese Belege nicht in beliebigen Chatverläufen auf, wenn sie Kundenpfade oder Anfrageinhalte enthalten. Füge niemals Authorization-Header, Cookies, private Client-Schlüssel oder vollständige Umgebungsdateien in ein Vorfallticket ein. Eine Zertifikatsuntersuchung rechtfertigt kein zweites Geheimnisleck.

Verwende einen kurzen Vorfallsdatensatz mit klarer Zuständigkeit:

1. Bestimme eine Person, die den Agenten stoppen kann, und eine Person, die für den Endpunkt oder Netzwerkpfad verantwortlich ist.
2. Markiere, ob der Aufruf eine Stelle zur Einfügung von Zugangsdaten erreicht hatte. Falls ja, gehe davon aus, dass die Zugangsdaten offengelegt worden sein könnten, bis der TLS-Peer identifiziert ist.
3. Bewahre Sitzungskennung und fehlgeschlagenen Aktionsdatensatz des Agenten auf und verhindere automatische Wiederholungen für dieses Ziel.
4. Lege einen Prüfpunkt für die Wiederherstellung fest. Die Person, die die API benötigt, sollte nicht allein entscheiden, dass ein neues Stammzertifikat vertrauenswürdig ist.

Das ist keine Bürokratie. Teams haben schon den größten Teil eines Vorfalls damit verbracht, Befehle zu testen, während ein Hintergrundprozess alle paar Sekunden denselben fehlerhaften Endpunkt erneut aufrief. Die Diagnose wurde dadurch selbst Teil der Gefährdung. Stoppe zuerst das Verhalten.

Lass den Agenten das Vertrauensproblem nicht durch Änderungen an globalen Laufzeiteinstellungen «reparieren». Prompts mit Vorschlägen wie `curl -k`, `verify=False`, einem pauschalen eigenen CA-Bundle oder deaktivierter Node.js-Prüfung sind genauso zu behandeln wie die Aufforderung, ein API-Token auszugeben. Der Agent kann nicht feststellen, ob ein überraschendes Zertifikat eine freigegebene Änderung ist, nur weil eine Websuche den Fehler als häufig bezeichnet.

## Das Zertifikat sichern, ohne ein Geheimnis zu senden

Du kannst ein Serverzertifikat untersuchen, ohne dich bei der API zu authentifizieren. Verwende einen nicht authentifizierten Health-Endpunkt, falls es einen gibt, oder baue einen Handshake auf und stoppe vor jeder Anwendungsanfrage. Führe die Prüfung auf demselben Rechner und in demselben Netzwerk aus, in dem der Fehler aufgetreten ist, da Proxy-Einstellungen, Unternehmens-Trustroots und Split-DNS sich zwischen Rechnern unterscheiden können.

Dieser Befehl fordert über SNI den vorgesehenen Servernamen an, prüft den gewünschten Hostnamen, zeigt die vom Peer gesendeten Zertifikate und bricht bei einem Prüfungsfehler ab:

```sh
openssl s_client \
  -connect api.example.com:443 \
  -servername api.example.com \
  -verify_hostname api.example.com \
  -verify_return_error \
  -showcerts </dev/null
```

Ein sauberes Ergebnis endet ungefähr so:

```text
Verification: OK
Verify return code: 0 (ok)
```

Speichere die Ausgabe bei einem Fehler als geschützten Vorfallsbeleg. Nützlich sind Subject, Aussteller, die Daten `Not Before` und `Not After`, Subject Alternative Names und jedes Zertifikat der Kette. Die PEM-Blöcke ermöglichen dem Betreiber des Endpunkts, den Empfang deines Rechners mit der erwarteten Serverkonfiguration zu vergleichen. Es sind öffentliche Zertifikate, aber gehe sorgfältig mit ihnen um, da Hostnamen und interne Aussteller trotzdem Infrastrukturdetails offenlegen können.

Teste anschließend das normale Clientverhalten ohne Authorization-Header:

```sh
curl --verbose --fail --show-error \
  https://api.example.com/health
```

Das ausführliche Protokoll zeigt TLS-Version, ausgewähltes Zertifikat und Prüfmeldung. Schwärze Anfragepfade, wenn sie Mandantennamen verraten. Füge nicht `-k` hinzu, damit der Befehl erfolgreich endet. Die fehlgeschlagene Prüfung ist der benötigte Beleg.

Ein häufiger Diagnosefehler ist das Weglassen von `-servername`. Viele gehostete Endpunkte wählen Zertifikate anhand von SNI und liefern ein Standardzertifikat, wenn der Client es nicht mitsendet. Dadurch entsteht ein Hostname-Mismatch, der den echten Client nie betroffen hat. Ein weiterer Fehler ist, `openssl s_client` ohne `-verify_hostname` auszuführen und ein Ergebnis der Kettenprüfung als Beweis für einen passenden Hostnamen zu behandeln. Das ist es nicht.

Notiere die aufgelöste Adresse separat mit deinem üblichen DNS-Diagnosewerkzeug. Mache die Übereinstimmung der Adresse nicht zum einzigen Test. Große Anbieter verwenden legitimerweise viele Adressen, während ein Angreifer eine plausibel aussehende DNS-Antwort kontrollieren kann. Zertifikatsname, Ausstellerpfad, Netzwerkpfad und freigegebener Änderungsdatensatz ergeben erst gemeinsam ein verlässliches Bild.

## Den Fehler klassifizieren, bevor du ihn reparierst

Zertifikatsfehler sehen im Log ähnlich aus, brauchen aber unterschiedliche Lösungen. Ordne die Belege einer Kategorie zu, bevor du die Vertrauenseinstellungen änderst. Sonst verschwindet zwar der sichtbare Fehler, während der ursprüngliche Routing- oder Deployment-Fehler bestehen bleibt.

Ein abgelaufenes Zertifikat bedeutet meist, dass der Betreiber die Erneuerung verpasst oder das neue Leaf-Zertifikat nicht ausgerollt hat. Vergleiche das Gültigkeitsintervall des gesicherten Zertifikats mit einer vertrauenswürdigen Uhr. Eine falsche Uhr kann ein aktuelles Zertifikat als abgelaufen oder noch nicht gültig erscheinen lassen. Prüfe daher zuerst die Clientzeit, bevor du einen Anbieter um eine Rotation bittest.

Ein Hostname-Mismatch bedeutet, dass der Server die Inhaberschaft des vom Client angeforderten Namens nicht nachgewiesen hat. Häufige Ursachen sind eine falsche API-Basis-URL, ein SNI-Konfigurationsfehler, ein Standard-Virtual-Host, veraltetes DNS oder ein Proxy-Zertifikat für einen anderen Namen. Akzeptiere keinen alternativen Namen, nur weil er ähnlich aussieht. `api.example.com` und `api.internal.example.com` können unterschiedliche Dienste und Vertrauensgrenzen darstellen.

Ein unbekannter Aussteller kann bedeuten, dass dem Client eine legitime private Stamm- oder Zwischenzertifizierungsstelle fehlt. Es kann auch bedeuten, dass ein nicht freigegebenes TLS-Inspektionsgerät ein Ersatz-Leaf-Zertifikat ausgestellt hat. Vergleiche Aussteller und Kette über einen unabhängigen Kanal mit den veröffentlichten oder dokumentierten Deployment-Informationen des Endpunktbetreibers. Eine Chatnachricht aus demselben System, das den Fehler verursacht hat, ist keine unabhängige Bestätigung.

Eine unvollständige Kette ist meistens ein Fehler des Endpunkts. Server müssen das Leaf-Zertifikat und die erforderlichen Zwischenzertifikate senden. Clients sollten nur ihre Vertrauensanker bereits besitzen. Ein fehlendes Zwischenzertifikat lokal zu installieren kann die fehlerhafte Serverkonfiguration auf einem Rechner verdecken und alle anderen Aufrufer fehlschlagen lassen. Bitte den Serverbetreiber, die korrekte Kette auszuliefern.

Ein selbstsigniertes Leaf-Zertifikat verdient besondere Vorsicht. Für einen internen Entwicklungsdienst kann es normal sein, allein liefert es jedoch keinen öffentlichen Identitätsnachweis. Eine verwaltete private CA funktioniert gut, wenn Administratoren ihre Stammzertifizierungsstelle über einen freigegebenen Geräte- oder Workload-Truststore verteilen und dokumentieren, wer sie kontrolliert. Ein zufälliges, von einem Endpunktbetreiber per E-Mail versendetes selbstsigniertes Zertifikat ist kein Vertrauenskonzept.

Gehe mit Zertifikatswiderruf sorgfältig um. Viele Clients führen Online-Widerrufsprüfungen nicht in jeder Umgebung zuverlässig aus, und Netzwerkfehler können diese Prüfungen beeinflussen. Behaupte nicht, ein Zertifikat sei sicher, nur weil ein einfacher Handshake `0 (ok)` zurückgibt. Meldet ein Betreiber einen kompromittierten privaten Schlüssel oder ein widerrufenes Zertifikat, blockiere das Ziel, rotiere offengelegte Zugangsdaten und lasse ein Ersatz-Zertifikat ausrollen.

## Serverpfad und Proxypfad getrennt prüfen

Ein verwalteter Proxy darf TLS legitim beenden und Ersatz-Zertifikate ausstellen, aber das muss ausdrücklich festgelegt sein. Wenn ein Rechner plötzlich einen unbekannten Unternehmensaussteller sieht, erkläre ihn nicht für harmlos, nur weil der Subject den Firmennamen enthält. Bestätige den Proxy-Rollout, die freigegebene Stammzertifizierungsstelle, den Geltungsbereich und ob API-Daten und Zugangsdaten ihn passieren dürfen.

Prüfe die Proxy-Konfiguration der Umgebung, ohne Werte auszugeben, die Zugangsdaten enthalten können. In einer Unix-ähnlichen Shell werden nur die Namen gesetzter Proxy-Variablen ausgegeben:

```sh
for n in HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY http_proxy https_proxy all_proxy no_proxy; do
  [ -n "${!n}" ] && printf '%s is set\n' "$n"
done
```

Eine Proxy-Einstellung kann erklären, warum dieselbe API über eine Mobilverbindung funktioniert, im Büronetzwerk aber fehlschlägt. Sie genehmigt den Proxy nicht. Vergleiche Ergebnisse in einem autorisierten alternativen Netzwerk nur, wenn die Regeln deiner Organisation das erlauben. Ändert sich der Zertifikatsaussteller mit dem Netzwerk, dokumentiere das Ergebnis und gib es an den Netzwerkverantwortlichen weiter.

Prüfe auch Änderungen bei Namensauflösung und Routing. Ein veralteter DNS-Eintrag nach einer Migration kann Aufrufe an einen alten Load-Balancer senden, der ein ausgemustertes Zertifikat präsentiert. Split-Horizon-DNS kann Bürogeräten eine interne Adresse mit privatem Zertifikat und anderen Geräten eine öffentliche Adresse liefern. Solche Designs lassen sich reparieren, der Client muss aber dem für die Route passenden Aussteller vertrauen und weiterhin den angeforderten Hostnamen prüfen.

Umgehe das Problem nicht durch eine fest codierte IP-Adresse. HTTPS-Identitätsprüfungen verwenden DNS-Namen, und eine direkte IP kann das vorgesehene Routing umgehen, die SNI-Auswahl stören oder ein DNS-Kontrollproblem verdecken. Ein IP-Override kann für einen streng kontrollierten Diagnosetest gelegentlich sinnvoll sein, braucht aber die Zustimmung des Endpunktbetreibers und darf niemals zur dauerhaften Agent-Konfiguration werden.

Proxys werfen außerdem eine Frage zur Datenverwaltung auf, die ein Zertifikatsfehler allein nicht beantwortet. Beendet der Proxy TLS, kann er API-Inhalte und eingefügte Zugangsdaten lesen. Das Sicherheitsteam muss entscheiden, ob diese Inspektion für die API zulässig ist. Dass der Endpunkt wieder funktioniert, sagt nichts darüber aus, ob der neue Pfad akzeptabel ist.

## Vertrauen in private CAs eng begrenzen und prüfbar halten

Private Zertifizierungsstellen lösen ein echtes Problem bei internen APIs, Entwicklungsumgebungen und kontrollierten Service-Meshes. Sie werden riskant, wenn Teams Stammzertifikate informell verteilen und vergessen, welche Prozesse ihnen vertrauen. Ein Stammzertifikat gibt seinem Besitzer weitreichende Möglichkeiten, Identitäten innerhalb seiner Vertrauensdomäne auszustellen. Es hinzuzufügen ist daher eine administrative Sicherheitsänderung und keine bloße Kompatibilitätsanpassung.

Installiere eine freigegebene private Stammzertifizierungsstelle über das verwaltete Betriebssystem, das Container-Image oder den Anwendungstruststore, der den Aufruf kontrolliert. Dokumentiere Subject, Fingerabdruck, Verantwortlichen, vorgesehene DNS-Suffixe, Freigabedatum und Entfernungspfad. Begrenze den Vertrauensbereich, wenn die Laufzeit das ermöglicht. Eine Entwicklungs-CA sollte nicht stillschweigend von jedem Produktionsagenten auf jedem Rechner vertraut werden.

Vertraue nicht als Abkürzung für einen fehlenden CA-Prozess einem einzelnen Leaf-Zertifikat. Leaf-Trust bricht bei der Erneuerung und verleitet dazu, PEM-Strings in Repositories einzufügen. Außerdem wird es schwer, eine geplante Rotation von einem unerwarteten Austausch zu unterscheiden. Wenn du beide Seiten kontrollierst, richte stattdessen einen privaten CA-Prozess mit geschütztem Signaturmaterial, dokumentierter Ausstellung und geplanter Rotation ein.

mTLS fügt eine eigene Identitätsrichtung hinzu. Bei gewöhnlichem HTTPS prüft der Client das Serverzertifikat. Bei mTLS fordert der Server zusätzlich ein Clientzertifikat an. Ein Fehler wie «alert certificate required» oder «bad certificate» kann bedeuten, dass der Client kein eigenes Zertifikat gesendet hat, eines vom falschen Aussteller präsentiert oder keinen passenden privaten Schlüssel besitzt. Die Deaktivierung der Serverprüfung würde dabei nicht helfen.

Halte private Client-Schlüssel aus Prompts, Shell-Snippets und Agent-Arbeitsbereichen heraus. Gib dem kontrollierten Aufrufer über einen Betriebssystem-Store oder einen anderen geschützten Mechanismus Zugriff auf die Zugangsdaten. Falls ein Clientzertifikat oder sein privater Schlüssel über eine nicht verifizierte TLS-Verbindung übertragen worden sein könnte, widerrufe oder ersetze es nach dem Verfahren der ausstellenden CA. Behandle es anders als ein Serverzertifikat, aber keinesfalls sorglos.

Auch Certificate Pinning verursacht mitunter Ausfälle trotz guter Absichten. Das Pinning eines Leaf-Zertifikats bindet den Client an ein bestimmtes Erneuerungsartefakt, sodass eine normale Rotation alle Agenten stoppen kann. Pinning kann bei einer engen, besonders risikoreichen Integration sinnvoll sein, wenn Betreiber Ersatz-Pins pflegen und die Rotation testen. Die meisten Teams fahren besser mit Hostname-Prüfung, verwalteten freigegebenen Trustroots und Überwachung der Zertifikatslaufzeit.

## Zugriff erst nach einer unabhängigen Prüfung wiederherstellen

Stelle den Agenten erst wieder frei, wenn jemand die Reparatur außerhalb des fehlgeschlagenen Agent-Workflows geprüft hat. Die Prüfung muss den tatsächlichen Hostnamen, den erwarteten Truststore und einen Client verwenden, der die normale Prüfung durchführt. Ein Browser reicht oft nicht aus, da Browser und Kommandozeilenclients unterschiedliche Proxy-Einstellungen und Truststores verwenden können.

Prüfe bei einer öffentlichen API, dass die präsentierte Kette zu einer erwarteten öffentlichen Trustroot führt, die Subject Alternative Names den konfigurierten Hostnamen enthalten und der Endpunktbetreiber Deployment oder Erneuerung über eine dokumentierte Änderung bestätigt. Prüfe bei einer privaten API die freigegebene private Stammzertifizierungsstelle, Aussteller, Hostname und erwarteten Netzwerkpfad. Bewahre das erfolgreiche Befehlsergebnis neben dem ursprünglichen Fehler auf.

Führe danach über denselben Pfad, den der Agent verwendet, eine authentifizierte Aktion mit geringen Auswirkungen aus. Wähle einen schreibgeschützten Endpunkt oder eine harmlose Identitätsprüfung, sofern die API das anbietet. Beobachte nach Möglichkeit Aktionslog und serverseitigen Audit-Eintrag. Bestätige Zielhostname, Antwortstatus und verwendete Zugangsdaten. Stelle nicht als ersten Test einen umfassenden Batch-Job wieder her.

Falls die früheren Fehler die Möglichkeit offenlassen, dass ein Token, eine signierte Anfrage oder eine mTLS-Zugangsdaten an einen Betrüger gelangt ist, rotiere sie vor der normalen Fortsetzung. Teams sträuben sich oft gegen die Rotation, weil die Belege unvollständig sind. Das ist der falsche Schluss. Gerade wegen der unvollständigen Beweislage muss eine Zugangsdaten, die eine nicht verifizierte Verbindung passiert hat, als offengelegt behandelt werden.

Dokumentiere die genaue Reparatur und nicht nur «TLS repariert». Eine brauchbare Abschlussnotiz sagt, dass der Endpunktbetreiber ein Zwischenzertifikat ausgerollt, der verwaltete Truststore eine bestimmte freigegebene Stammzertifizierungsstelle erhalten oder eine Proxy-Konfiguration entfernt hat. Sie nennt außerdem, wer den Hostnamen geprüft hat und welche Agent-Läufe wieder aufgenommen wurden. So verhindert sie, dass der nächste Verantwortliche bei der nächsten Erneuerung wieder eine unsichere Umgehung einführt.

## Den sicheren Weg einfacher machen als die Umgehung

Das Verfahren scheitert, wenn sichere Behandlung Stunden dauert und die Umgehung nur eine Umgebungsvariable braucht. Baue die Agent-Integration so, dass sie keinen unsicheren TLS-Modus wählen, keine globale Vertrauenskonfiguration ändern und bei der Fehlersuche keine langlebigen Zugangsdaten sehen kann. Stelle Verbindungseinstellungen, freigegebene Hostnamen und Vertrauensmaterial unter die normale Änderungsprüfung.

Sallyport kann API-Zugangsdaten in einem verschlüsselten Tresor verwahren und HTTP-Aufrufe für einen Agenten ausführen, sodass der Agent die Zugangsdaten selbst nie erhält. Sitzungs- und Aufrufprotokolle können außerdem festhalten, wer die Aktion versucht hat. Trotzdem muss ein Mensch entscheiden, ob ein geändertes Zertifikat eine freigegebene Änderung oder ein gefährlicher Pfad ist.

Löse bei wiederholten Prüfungsfehlern und bei Versuchen, bekannte Umgehungen aufzurufen, einen Alarm aus. Ein fehlgeschlagener Aufruf sollte genügend strukturierte Informationen für Hostname, Fehlerklasse und Agent-Lauf enthalten, aber kein Geheimnis. Gib Agenten eine feste Anweisung: Bei Zertifikatsprüfungsfehlern stoppen, den exakten Fehler und Endpunkt melden und eine menschliche Prüfung anfordern. Suche nicht nach einem Workaround.

Die erste sinnvolle Reparatur ist meist unspektakulär: Entferne bereits vorhandene Schalter für unsichere Prüfung aus Skripten und sorge dafür, dass der normale Client einen verwalteten Truststore verwendet. Teste anschließend die Zertifikatserneuerung, bevor sie dich in der Produktion überrascht. Teams, die eine Erneuerung und einen Vorfall mit unerwartetem Aussteller durchspielen, reagieren schneller als Teams, deren einziger TLS-Plan aus einem aus einem Forum kopierten Befehl besteht.

Eine Zertifikatswarnung hat ihre Aufgabe erfüllt, wenn sie einen Aufruf unterbricht, der nicht fortgesetzt werden sollte. Lass es dabei bleiben.