Was prüft dieser Test?
Der KernelHost SSL-Checker holt das Server-Zertifikat per TLS-Handshake aus Frankfurt und liefert dir die wichtigsten Felder ohne externe Drittanbieter. Folgendes wird geprüft und angezeigt:
- Ausstellung und Aussteller: Common Name (Subject CN), die volle Subject-DN und der Issuer (also welche CA das Zertifikat unterschrieben hat).
- Gültigkeitszeitraum: Start- und Enddatum in UTC plus die verbleibenden Tage. Farbcode grün (>30 Tage), orange (7 bis 30 Tage), rot (unter 7 Tagen oder bereits abgelaufen).
- Subject Alternative Names (SANs): Komplette Liste der Hostnamen die das Zertifikat absichert, inklusive Wildcard-Einträgen.
- Hostname-Match: Prüfung ob die eingegebene Domain wirklich vom Common Name oder einer SAN-Wildcard abgedeckt ist (RFC 6125).
- Schlüssel und Signatur: Public-Key-Algorithmus (RSA, ECDSA), Schlüsselgröße in Bit beziehungsweise Kurvenname und der Signatur-Algorithmus.
- Fingerprints und Seriennummer: SHA-256 und SHA-1 Fingerprint des DER-codierten Zertifikats sowie die hexadezimale Seriennummer.
- Komplette Chain: Alle Zertifikate die der Server im Handshake mitgeliefert hat, mit Subject, Issuer und Rolle (Leaf, Intermediate, Root).
Häufige SSL-Fehler und was sie bedeuten
Browser zeigen oft kryptische Fehler wie NET::ERR_CERT_DATE_INVALID oder SSL_ERROR_BAD_CERT_DOMAIN. Hier die häufigsten Ursachen und wie du sie behebst:
- Zertifikat abgelaufen: Das Enddatum (notAfter) liegt in der Vergangenheit. Browser blockieren die Seite komplett. Lösung: Zertifikat erneuern, bei Let's Encrypt automatisch alle 60 Tage per certbot oder acme.sh.
- Hostname stimmt nicht überein: Der eingegebene Hostname taucht weder im Common Name noch in den SANs auf. Lösung: Bei Neuausstellung alle gewünschten Domains und Subdomains als SAN hinzufügen.
- Selbst signiert oder unbekannte CA: Issuer ist keine vertrauenswürdige Root-CA. Browser zeigen NET::ERR_CERT_AUTHORITY_INVALID. Lösung: Zertifikat von einer anerkannten CA wie Let's Encrypt, ZeroSSL, Sectigo oder DigiCert holen.
- Unvollständige Chain: Server liefert nur das Leaf-Zertifikat, ohne die Intermediates. Mobile Browser und alte Geräte zeigen dann Fehler. Lösung: Voll-Chain (fullchain.pem) im Webserver konfigurieren.
- Schwacher Schlüssel oder schwache Signatur: RSA unter 2048 Bit oder SHA-1-Signatur sind nicht mehr akzeptiert. Lösung: Neu ausstellen mit RSA 2048+ oder ECDSA P-256.
- Mixed Content und HSTS-Stolperfalle: Wenn ein gültiges HSTS-Header gesetzt war und das Zertifikat dann abgelaufen ist, können Besucher die Warnung nicht mehr wegklicken. Sofortmaßnahme: Cert erneuern, HSTS-max-age im Notfall reduzieren.
Let's Encrypt vs. kommerzielle Zertifikate
Let's Encrypt ist eine kostenlose, automatisierte CA von der ISRG. Die Zertifikate sind technisch identisch zu kommerziellen DV-Zertifikaten und werden von allen modernen Browsern als vertrauenswürdig akzeptiert.
Wann lohnt sich ein kostenpflichtiges Zertifikat? Eigentlich nur in Sonderfällen:
- Extended Validation (EV): Früher mit grüner Adressleiste, heute optisch kaum noch erkennbar. Lohnt sich nur für Banken oder Börsen wenn rechtliche Anforderungen das vorschreiben.
- Wildcard ohne DNS-Challenge: Let's Encrypt unterstützt Wildcards nur via DNS-01-Challenge. Wer keinen API-Zugriff zum DNS hat, greift zu ZeroSSL Premium oder Sectigo.
- Garantie und Versicherung: Kommerzielle CAs bieten Versicherungssummen bei Fehlausstellung. Praktisch fast nie relevant, aber manche Compliance-Frameworks verlangen das.
Bei KernelHost Webhosting und cPanel ist die Let's Encrypt-Integration kostenlos enthalten und automatisiert. Zertifikate werden per AutoSSL alle 60 Tage erneuert, ohne dass du etwas tun musst. Auch Wildcard-Zertifikate per DNS-Challenge sind möglich, sobald die Domain im KernelHost-DNS liegt.
TLS 1.2 vs. TLS 1.3
TLS 1.2 ist seit 2008 Standard, TLS 1.3 wurde 2018 als RFC 8446 veröffentlicht und ist seit 2020 weit verbreitet. ältere Versionen (SSL 3.0, TLS 1.0, TLS 1.1) sind unsicher und sollten in der Server-Konfiguration deaktiviert sein.
Was TLS 1.3 besser macht:
- Schnellerer Handshake: 1-RTT statt 2-RTT, plus optionales 0-RTT bei Wiederverbindung. Spürbar schneller bei TLS-lastigen Seiten.
- Weniger Cipher-Wildwuchs: Nur noch 5 erlaubte AEAD-Cipher-Suites. Keine RSA-Key-Exchange mehr, immer Forward Secrecy.
- Verschlüsselter Handshake: Server-Zertifikat selbst wird verschlüsselt übertragen. Mit ESNI/ECH ist sogar das SNI privat.
- Backwards-Kompatibel: Server können TLS 1.2 und 1.3 parallel anbieten. Browser handeln automatisch die höchste gemeinsame Version aus.
Was bedeutet ein abgelaufenes Zertifikat?
Ein abgelaufenes SSL-Zertifikat bedeutet konkret: Browser zeigen eine Vollbild-Warnung und blockieren die Seite. Besucher können die Warnung in den meisten Fällen nicht einfach wegklicken, vor allem nicht bei aktivem HSTS-Header.
Konsequenzen für den Betreiber:
- Ranking-Verlust bei Google (HTTPS ist Ranking-Faktor und vertrauensbezogene Signale werden ausgewertet).
- Mail-Server (MX/SMTP mit STARTTLS) verweigern eingehende Verbindungen, Mails bouncen oder werden verzögert zugestellt.
- API-Clients und Mobile-Apps mit Certificate-Pinning brechen ab und müssen unter Umständen ein App-Update bekommen.
HSTS, CAA und OCSP-Stapling
Ein gültiges Zertifikat ist erst der Anfang. Drei zusätzliche Mechanismen heben TLS-Sicherheit auf Best-Practice-Level:
- HSTS (HTTP Strict Transport Security): Header der Browser zwingt, künftig nur noch HTTPS zu nutzen. Empfehlung: max-age=63072000; includeSubDomains; preload (zwei Jahre, alle Subdomains, Preload-Liste). Vorsicht beim Aktivieren, weil ein Fehler nicht zurückrollbar ist solange max-age noch läuft.
- CAA (Certification Authority Authorization): DNS-Eintrag der festlegt welche CA Zertifikate für deine Domain ausstellen darf. Beispiel: 'kernelhost.com. CAA 0 issue "letsencrypt.org"' verhindert Mis-Issuing durch andere CAs.
- OCSP-Stapling: Webserver liefert die Sperrstatus-Antwort der CA gleich mit, statt dass jeder Browser separat bei der CA nachfragt. Schneller für Besucher und schont die CA-Infrastruktur. In Apache: SSLUseStapling On, in nginx: ssl_stapling on.
Datenschutz
Der KernelHost SSL-Checker läuft komplett in unserem Frankfurt-Knoten ohne Drittanbieter-Calls:
- Keine Weitergabe der Eingabe an externe APIs (kein SSL Labs, kein Hardenize, kein Cryptomon).
- Keine Speicherung der geprüfte Domain über das Request-Logging hinaus (Standard-Webserver-Log, 14 Tage Aufbewahrung).
- Anti-SSRF-Filter blockt Anfragen auf private IP-Bereiche, Loopback und Link-Local.
- Rate-Limit pro IP gegen Missbrauch. Optional hCaptcha bei Submit.