PAGUP Agent ControlWordPress-Zugriff für KI-Assistenten
Kostenlos testen

Warum WAP AI Assistant auf einer HTTPS-Website eine HTTPS-Warnung anzeigt

Ein gültiges Schlosssymbol im Browser bestätigt die Verbindung zwischen Besucher und Edge, beweist aber nicht allein, was WordPress am Origin empfängt. Reverse Proxy, Load Balancer oder CDN-Verschlüsselungsmodus können dazu führen, dass der Browser HTTPS nutzt, die Anfrage WordPress jedoch über HTTP erreicht.

Dieselbe Warnung kann auch erscheinen, wenn die HTTPS-Erkennung korrekt ist, Anwendungspasswörter jedoch global oder für den aktuellen Benutzer deaktiviert sind. Prüfen Sie beide Bedingungen getrennt.

Wahrscheinliche Ursachen

  • Der Browser nutzt HTTPS, aber WordPress erkennt die Anfrage am Origin nicht als sicher.
  • Ein Sicherheits-Plugin, Must-use-Plugin oder benutzerdefinierter Filter deaktiviert Application Passwords global.
  • Die installierte Plugin-Version zeigt einen falschen oder veralteten HTTPS-Hinweis.
  • WordPress Home URL und Site URL verwenden unterschiedliche Schemata, Hosts oder Pfade.
  • Ein anderes Plugin verändert HTTPS-Erkennung, REST-Zugriff oder Verfügbarkeit von Application Passwords.

Diagnosereihenfolge

  1. Erfassen Sie die genaue bereinigte Meldung, den HTTP-Status und Response-Body ohne Geheimnisse.
  2. Dokumentieren Sie WordPress-, Plugin-, Client-, Connector- und Serverversionen vor jeder Änderung.
  3. Prüfen Sie, ob die exakt verwendete URL mit gültiger HTTPS-Verbindung lädt.
  4. Prüfen Sie, ob WordPress selbst die Anfrage als HTTPS erkennt, nicht nur der Browser.
  5. Prüfen Sie die globale Verfügbarkeit von Application Passwords in der aktiven Umgebung.
  6. Vergleichen Sie Home URL, Site URL, öffentlichen kanonischen Host und REST-Basisadresse.
  7. Vergleichen Sie die installierte Version mit offiziellem Changelog und Korrekturversionen.

Die kleinste passende Korrektur anwenden

  1. Korrigieren Sie vertrauenswürdige Proxy- und Origin-Verarbeitung, damit WordPress die ursprüngliche HTTPS-Anfrage erkennt.
  2. Entfernen oder begrenzen Sie den deaktivierenden Filter erst nach Bestätigung der gewünschten Sicherheitsrichtlinie.
  3. Richten Sie Home URL, Site URL, öffentlichen Host, HTTPS-Schema und REST-Basis aus.
  4. Aktualisieren Sie auf die Plugin-Version, die das beobachtete Verhalten dokumentiert oder korrigiert.
  5. Eskalieren Sie mit bereinigter versionierter Evidenz, wenn das Verhalten pluginspezifisch bleibt.

Ergebnis überprüfen

  • Der Hinweis verschwindet nur unter der korrigierten Bedingung und kehrt nicht auf unbeteiligten Adminseiten zurück.
  • Der REST-Index antwortet über die kanonische HTTPS-URL und zeigt erwartete Namespaces.
  • Die authentifizierte Anfrage erreicht den kanonischen Endpunkt ohne unerwartete Weiterleitung.
  • Die authentifizierte Anfrage entspricht dem vorgesehenen dedizierten Benutzer.

Was Sie nicht tun sollten

  • Vergeben Sie keinen Administratorzugriff nur damit ein Verbindungstest gelingt.
  • Fügen Sie keinen ungeprüften dauerhaften Proxy-Workaround vor Bestätigung des Vertrauenspfads hinzu.
  • Deaktivieren Sie WAF oder Sicherheits-Plugin nicht global für eine einzelne Anfrage.
  • Teilen Sie kein Application Password, keinen Authorization-Header, Token oder Cookie in Prompt, Ticket, Log oder Screenshot.
  • Bezeichnen Sie Hinweis oder Anmeldedaten ohne Beleg nicht als Malware, Backdoor oder Kompromittierung.

Verwandte Leitfäden

Quellen und Überprüfung

Diese Seite wurde anhand der folgenden Primärquellen überprüft. Letzte Quellenprüfung: .