So funktioniert’s
Browser und Mailserver vertrauen nicht jedem Zertifikat direkt, sondern einer überschaubaren Zahl von Stammzertifikaten (Root-CAs) in ihrem Zertifikatsspeicher. Root-CAs signieren Serverzertifikate in der Regel nicht selbst, sondern über ein oder zwei Zwischenzertifikate (Intermediate CAs). Die Kette führt also vom Serverzertifikat über die Zwischenzertifikate bis zu einer Wurzel, der der Client vertraut.
Der Server muss im Handshake sein eigenes Zertifikat und alle Zwischenzertifikate mitschicken, die Wurzel nicht. Bei Let’s Encrypt steckt das in der Datei fullchain.pem; wer stattdessen cert.pem einbindet, liefert nur das Serverzertifikat aus.
Ein selbstsigniertes Zertifikat hat sich selbst ausgestellt: Aussteller und Inhaber sind identisch, keine öffentliche CA bürgt dafür. Für interne Tests ist das in Ordnung, öffentlich ist es gleichbedeutend mit einer ungültigen Kette. Typisch sind die Standardzertifikate von Reverse-Proxys wie Traefik oder von Hosting-Panels, die ausgeliefert werden, wenn für einen Hostnamen kein eigenes Zertifikat eingerichtet ist.
Warum gefährlich
Ein fehlendes Zwischenzertifikat ist tückisch, weil es im Desktop-Browser oft nicht auffällt: Viele Browser laden es über die Adresse im Zertifikat nach oder kennen es bereits. curl, PHP, Java, ältere Android-Geräte, Zahlungsdienste und Webhooks tun das nicht und brechen die Verbindung ab. Die Folge sind scheinbar zufällige Fehler, bei denen jeder sagt: „Bei mir geht’s.“
Ein selbstsigniertes oder fremdes Standardzertifikat führt im Browser zur ganzseitigen Warnung. Auf Mailservern stellen Absender mit MTA-STS oder DANE nicht mehr zu; Absender ohne diese Verfahren verschlüsseln zwar weiter, prüfen aber nicht, mit wem sie sprechen.
So vermeidest du es
- Immer die vollständige Kette einbinden: bei Let’s Encrypt fullchain.pem, bei gekauften Zertifikaten das Bundle der CA in der richtigen Reihenfolge (Serverzertifikat zuerst, dann die Zwischenzertifikate).
- Nach jeder Installation von außen testen, etwa mit openssl s_client -connect example.com:443 -servername example.com -showcerts, und auf „Verify return code: 0 (ok)“ achten.
- Die Kette vom ACME-Client oder Hosting mitliefern lassen, statt eine alte Bundle-Datei fest einzutragen – CAs wechseln ihre Zwischenzertifikate regelmäßig.
- Für jeden öffentlich erreichbaren Hostnamen ein echtes Zertifikat einrichten oder den DNS-Eintrag löschen, damit kein Proxy-Standardzertifikat ausgeliefert wird.
- Selbstsignierte Zertifikate nur intern nutzen und Mailserver mit einem öffentlichen Zertifikat ausstatten, dessen Name zum MX-Hostnamen passt.
So erkennt DomainWarn es
Der Check „Zertifikat“ verifiziert die mitgeschickte Kette gegen die üblichen Stammzertifikate, ohne fehlende Zwischenzertifikate nachzuladen – so, wie es curl oder ein Mailserver tut. Eine unvollständige oder nicht vertrauenswürdige Kette ergibt den Befund „Die Zertifikatskette ist nicht gültig“ mit dem genauen Grund (etwa „unable to verify the first certificate“), ein selbstsigniertes Zertifikat den Befund „Das Zertifikat ist selbst signiert“. Beides ist kritisch und eröffnet nach zwei Läufen den Incident „Zertifikat ungültig“; die Zwischenzertifikate stehen mit Aussteller und Ablaufdatum im Ergebnis.
Für Mailserver prüft der SMTP-Check die Kette per STARTTLS (Incident „Mailserver-Zertifikat fehlerhaft“), und das Subdomain-Inventar findet Hostnamen, auf denen ein selbstsigniertes Standardzertifikat eines Proxys hängt (Incident „Ungültiges Zertifikat auf einer Subdomain“).
DomainWarn prüft das für alle deine Domains regelmäßig und meldet sich, wenn etwas fehlt oder sich ändert.