Was der SSL-Check prüft
Ein Browser zeigt dir nur, ob die Verbindung klappt. Er ergänzt dabei stillschweigend fehlende Zwischenzertifikate und nutzt seinen eigenen, aktuellen Zertifikatsspeicher. Apps, Mailprogramme, Java, curl und ältere Smartphones machen das nicht. Der SSL-Check zeigt die Kette so, wie dein Server sie wirklich ausliefert.
Server-Zertifikat
Geprüft werden der Hostname gegen das SAN-Feld (inklusive Wildcards wie *.beispiel.de), Beginn und Ende der Gültigkeit, die Schlüssellänge und der Signaturalgorithmus. Bei weniger als 30 Tagen Restlaufzeit gibt es einen Hinweis.
Zwischenzertifikate und Reihenfolge
Der Server muss sein eigenes Zertifikat und alle Zwischenzertifikate bis kurz vor die Root-CA mitschicken, und zwar in der Reihenfolge Server → Zwischen-CA → nächste Zwischen-CA. Fehlt ein Glied, funktioniert die Seite im Browser oft trotzdem, aber Apps und Mail-Clients melden „unable to get local issuer certificate“. Die Root-CA selbst muss nicht mitgeschickt werden.
Das Problem mit älteren Android-Geräten
Neuere Root-CAs wie GlobalSign Root R46, ISRG Root X2 oder die DigiCert G5-Roots sind erst ab Android 14 (Oktober 2023) im System-Zertifikatsspeicher. Android 13 und älter kennen sie nicht. Eine vom Server mitgeschickte Root-CA wird nie als vertrauenswürdig akzeptiert, sie zu ergänzen hilft also nicht.
Die Lösung ist ein Cross-Zertifikat: dieselbe CA mit demselben Schlüssel, aber beglaubigt von einer älteren Root, die auch alte Geräte kennen. Schickt der Server dieses Cross-Zertifikat mit, finden alte Geräte den Weg zur alten Root und neue Geräte weiterhin zur neuen. Der SSL-Check erkennt das Problem, und mit einem Klick baut der Zertifikat-Konverter das passende Cross-Zertifikat aus der Mozilla-CCADB in deine Kette ein.
Mailserver und STARTTLS
Für SMTP (Port 25 und 587), IMAP (143) und POP3 (110) verbindet sich der Check zuerst im Klartext und schaltet dann per STARTTLS auf TLS um, genau wie ein Mailprogramm. Ports mit direktem TLS wie 465, 993 und 995 werden sofort verschlüsselt angesprochen.
Sperrstatus, CAA und DANE
Zusätzlich fragt der Check den Sperrstatus des Zertifikats ab, per OCSP oder über die Sperrliste (CRL) der CA. Außerdem liest er den CAA-Eintrag der Domain und warnt, wenn der aktuelle Aussteller dort nicht erlaubt ist, denn dann scheitert die nächste Verlängerung. Gibt es für den Port einen TLSA-Eintrag (DANE), prüft er, ob dieser zum ausgelieferten Zertifikat passt und per DNSSEC abgesichert ist. Erstellen kannst du solche Einträge mit CAA & DANE.
Kette reparieren
- SSL-Check ausführen und auf „Im Konverter reparieren“ bzw. „Kette im Konverter ergänzen“ klicken.
- Der Konverter übernimmt die Kette, lädt fehlende Zwischenzertifikate über AIA nach und bietet passende Cross-Zertifikate an.
- Den privaten Schlüssel dazunehmen und das Format für deinen Server exportieren, etwa PEM-Bundle für nginx oder PFX für IIS.
- Auf dem Server einspielen, neu laden und hier noch einmal prüfen.
FAQ
Warum funktioniert meine Seite im Browser, aber nicht in der App?
Browser laden fehlende Zwischenzertifikate oft selbst nach. Apps, Java, curl und viele Mail-Clients tun das nicht und brechen ab. Der SSL-Check zeigt, ob dein Server die vollständige Kette ausliefert.
Muss ich die Root-CA mitschicken?
Nein. Clients vertrauen nur der Root-CA in ihrem eigenen Speicher. Eine mitgeschickte Root schadet nicht, kostet aber bei jedem Verbindungsaufbau ein paar Hundert Byte.
Warum lehnt Android 13 mein Zertifikat ab?
Vermutlich endet deine Kette bei einer Root-CA, die erst ab Android 14 im Speicher ist, etwa GlobalSign Root R46. Abhilfe schafft ein Cross-Zertifikat, das dieselbe CA unter einer älteren Root beglaubigt. Der Konverter baut es ein.
Kann ich auch Mailserver prüfen?
Ja. Wähle den Port, zum Beispiel 587 oder 25 für SMTP mit STARTTLS, 465 für SMTPS, 993 für IMAPS oder 143 für IMAP mit STARTTLS.
Was wird gespeichert?
Nichts. Der Server baut die Verbindung auf, gibt die Zertifikate an deinen Browser zurück und vergisst sie wieder. Zum Schutz vor Missbrauch ist die Zahl der Prüfungen pro Zeit begrenzt.