E-Mails werden erst versendet, nachdem jemand die Zertifikatsprüfung abgeschaltet hat. Das wirkt zunächst wie eine Lösung, kann WordPress aber mit dem falschen Mailserver oder einem TLS-prüfenden Proxy verbinden. Sicher ist nur eine Korrektur, bei der die Identität des Gegenübers wieder eindeutig geprüft wird.
Dieser Leitfaden zeigt, wie sich Fehler bei Hostnamen, Zertifikatskette, Systemzeit, TLS-Modus und Netzwerk-Interception unterscheiden und direkt vom WordPress-Server aus prüfen lassen.
- Was das Thema bedeutet
- Ein realistisches WordPress-Beispiel
- Warum es wichtig ist und wann es eingesetzt wird
- Der einfache Weg für Einsteiger
- Der technische Weg
- Risiken, häufige Fehler, Backup und Rollback
- Wie AIOWS unterstützt: AIOWS SMTP Manager
- Passende AIOWS-Artikel
- Fazit und empfohlener Weg
- Offizielle Quellen
Was das Thema bedeutet
Ein SMTP-TLS-Zertifikatsfehler bedeutet, dass WordPress den Maildienst erreicht, dessen Identität oder Zertifikatskette jedoch nicht bestätigen kann. Der konfigurierte Hostname muss in den Subject Alternative Names des Zertifikats enthalten sein. Außerdem muss der Server alle benötigten Zwischenzertifikate liefern und der WordPress-Host der ausstellenden Zertifizierungsstelle vertrauen.
Auch Port und Verschlüsselungsart müssen zusammenpassen. Port 465 verwendet üblicherweise implizites TLS; bei Port 587 beginnt die Verbindung meist als SMTP-Sitzung und wechselt anschließend per STARTTLS in die Verschlüsselung.
Ein realistisches WordPress-Beispiel
Eine Website verwendet seit Jahren einen alten SMTP-Alias. Nach einer Netzwerkänderung liefert der Handshake ein Zertifikat für den kanonischen Hostnamen des Anbieters. Sobald die Zertifikatsprüfung deaktiviert wird, funktioniert die Testmail – allerdings ohne Nachweis, dass WordPress tatsächlich mit dem vorgesehenen Dienst spricht.
Der Administrator aktiviert die Prüfung wieder, übernimmt den dokumentierten Hostnamen samt passendem TLS-Modus und testet vom Produktionsserver. Erscheint das fremde Zertifikat nur in diesem Netz, wird der Proxy oder die Sicherheitslösung untersucht, nicht die WordPress-Konfiguration umgangen.
Warum es wichtig ist und wann es eingesetzt wird
Zertifikatsfehler entstehen erst, nachdem die Verbindung die TLS-Phase erreicht hat. Der genaue Wortlaut – etwa Hostnamenabweichung, abgelaufenes Zertifikat, unbekannter Aussteller, unvollständige Kette oder Handshake-Fehler – weist deshalb oft direkt auf den zuständigen Bereich hin.
Eine IP-Adresse anstelle des SMTP-Hostnamens oder ein ungeprüft importiertes Zertifikat sind keine sauberen Lösungen. Beides kann den Identitätsfehler verdecken. Benötigt wird eine gültige Vertrauenskette für den offiziell dokumentierten Host.
Dieses Vorgehen passt zu Fehlern während des TLS-Handshakes. Fehlgeschlagene Anmeldung, abgelehnte Absender, Zeitüberschreitungen und Zustellprobleme müssen getrennt untersucht werden.
Der einfache Weg für Einsteiger
- Sichern Sie SMTP-Host, Port, Verschlüsselung und eventuell gesetzte Ausnahmen für die Zertifikatsprüfung.
- Vergleichen Sie die Konfiguration mit der Dokumentation des Anbieters. Prüfen Sie Systemzeit und CA-Paket des Servers.
- Aktivieren Sie Peer- und Hostnamenprüfung. Untersuchen Sie vom WordPress-Host aus Namen, Aussteller, Gültigkeit und vollständige Zertifikatskette.
- Korrigieren Sie die Einstellung oder lassen Sie ein abgelaufenes Zertifikat beziehungsweise fehlende Zwischenzertifikate vom zuständigen Anbieter beheben.
- Versenden Sie eine echte, von WordPress erzeugte Nachricht und prüfen Sie SMTP-Antwort und Eingang im kontrollierten Postfach.
Der technische Weg
Der Handshake muss vom selben Host und aus demselben Netz stammen wie der WordPress-Betrieb. Vergleichen Sie den eingestellten Hostnamen mit der SAN-Liste und testen Sie mit korrektem SNI. Bei STARTTLS muss der Server die Erweiterung nach EHLO anbieten; bei implizitem TLS beginnt die Verschlüsselung unmittelbar.
Prüfen Sie die gesamte Kette. Ein Desktop kann ein fehlendes Zwischenzertifikat aus seinem Cache ergänzen und dadurch einen falschen Erfolg vortäuschen. Vergleichen Sie den Gültigkeitszeitraum in UTC und notieren Sie die CA-Bundle-Version. Ersetzt ein Unternehmensproxy Zertifikate, darf dessen private Stammzertifizierungsstelle nur nach ausdrücklicher Freigabe auf den erforderlichen Systemen installiert werden.
Abgenommen ist die Korrektur erst nach einem verifizierten Handshake zum vorgesehenen Host, erfolgreicher Anmeldung und Zustellung einer echten WordPress-Nachricht.
Risiken, häufige Fehler, Backup und Rollback
Peer- oder Hostnamenprüfung darf in Produktion nicht deaktiviert bleiben. Feste IP-Adressen, ungeklärte Vertrauensanker und eine vom Anbieter abweichende Kombination aus Port und TLS-Modus können Zugangsdaten gefährden oder eine Interception verbergen.
Sichern Sie die SMTP-Konfiguration vor der Änderung. Scheitern verifizierter Handshake oder Versand, stellen Sie die vorherige sichere Konfiguration wieder her – nicht eine unsichere Ausnahme. Dokumentieren Sie das präsentierte Zertifikat, den Testzeitpunkt, den Endpunkt und die Zuständigkeit, ohne Zugangsdaten offenzulegen.
Wie AIOWS unterstützt:
AIOWS SMTP Manager
Der AIOWS SMTP Manager führt SMTP-Host, Port, Verschlüsselungsart und Absendereinstellungen auf WordPress-Seite an einer Stelle zusammen. So lässt sich erkennen, ob die Zertifikatsprüfung tatsächlich denselben Endpunkt und TLS-Modus verwendet wie der reguläre Mailversand der Website.
Nach der Korrektur von Hostname oder Zertifikatskette helfen Test und Diagnosekontext des Moduls bei der Kontrolle von WordPress-Transport und Providerantwort. Anschließend sollte eine echte Transaktionsmail, etwa eine gezielt ausgelöste E-Mail zum Zurücksetzen des Passworts, auch den Anwendungsweg bestätigen.
AIOWS kann weder ein Providerzertifikat erneuern noch den Trust Store des Servers oder einen Netzwerkproxy ändern. Dafür bleiben Mailanbieter, Hoster oder Netzwerkadministration zuständig. Das Modul hält die unterstützte WordPress-Konfiguration und ihr Testergebnis während dieser Arbeiten nachvollziehbar.
Passende AIOWS-Artikel
- WordPress-E-Mails landen im Spam: 10 wirksame Lösungen
- WordPress-SMTP-Verbindung: Zeitüberschreitung beheben
- WordPress-SMTP-Verbindung abgelehnt: Lösungen
Fazit und empfohlener Weg
Lassen Sie Zertifikats- und Hostnamenprüfung aktiv. Verwenden Sie den dokumentierten Endpunkt, beheben Sie den Fehler an Zertifikatskette, Uhrzeit, Trust Store oder autorisierter Interception und geben Sie die Änderung erst nach einem verifizierten Handshake und einem echten Versand vom WordPress-Server frei.
