Was prueft 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 geprueft und angezeigt:
- Ausstellung und Aussteller: Common Name (Subject CN), die volle Subject-DN und der Issuer (also welche CA das Zertifikat unterschrieben hat).
- Gueltigkeitszeitraum: Start- und Enddatum in UTC plus die verbleibenden Tage. Farbcode gruen (>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-Eintraegen.
- Hostname-Match: Pruefung ob die eingegebene Domain wirklich vom Common Name oder einer SAN-Wildcard abgedeckt ist (RFC 6125).
- Schluessel und Signatur: Public-Key-Algorithmus (RSA, ECDSA), Schluesselgroesse 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).
Haeufige 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 haeufigsten Ursachen und wie du sie behebst:
- Zertifikat abgelaufen: Das Enddatum (notAfter) liegt in der Vergangenheit. Browser blockieren die Seite komplett. Loesung: Zertifikat erneuern, bei Let's Encrypt automatisch alle 60 Tage per certbot oder acme.sh.
- Hostname stimmt nicht ueberein: Der eingegebene Hostname taucht weder im Common Name noch in den SANs auf. Loesung: Bei Neuausstellung alle gewuenschten Domains und Subdomains als SAN hinzufuegen.
- Selbst signiert oder unbekannte CA: Issuer ist keine vertrauenswuerdige Root-CA. Browser zeigen NET::ERR_CERT_AUTHORITY_INVALID. Loesung: Zertifikat von einer anerkannten CA wie Let's Encrypt, ZeroSSL, Sectigo oder DigiCert holen.
- Unvollstaendige Chain: Server liefert nur das Leaf-Zertifikat, ohne die Intermediates. Mobile Browser und alte Geraete zeigen dann Fehler. Loesung: Voll-Chain (fullchain.pem) im Webserver konfigurieren.
- Schwacher Schluessel oder schwache Signatur: RSA unter 2048 Bit oder SHA-1-Signatur sind nicht mehr akzeptiert. Loesung: Neu ausstellen mit RSA 2048+ oder ECDSA P-256.
- Mixed Content und HSTS-Stolperfalle: Wenn ein gueltiges HSTS-Header gesetzt war und das Zertifikat dann abgelaufen ist, koennen Besucher die Warnung nicht mehr wegklicken. Sofortmassnahme: 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 vertrauenswuerdig akzeptiert.
Wann lohnt sich ein kostenpflichtiges Zertifikat? Eigentlich nur in Sonderfaellen:
- Extended Validation (EV): Frueher mit gruener Adressleiste, heute optisch kaum noch erkennbar. Lohnt sich nur fuer Banken oder Boersen wenn rechtliche Anforderungen das vorschreiben.
- Wildcard ohne DNS-Challenge: Let's Encrypt unterstuetzt 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 moeglich, 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 veroeffentlicht und ist seit 2020 weit verbreitet. Aeltere 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. Spuerbar schneller bei TLS-lastigen Seiten.
- Weniger Cipher-Wildwuchs: Nur noch 5 erlaubte AEAD-Cipher-Suites. Keine RSA-Key-Exchange mehr, immer Forward Secrecy.
- Verschluesselter Handshake: Server-Zertifikat selbst wird verschluesselt uebertragen. Mit ESNI/ECH ist sogar das SNI privat.
- Backwards-Kompatibel: Server koennen TLS 1.2 und 1.3 parallel anbieten. Browser handeln automatisch die hoechste gemeinsame Version aus.
Was bedeutet ein abgelaufenes Zertifikat?
Ein abgelaufenes SSL-Zertifikat bedeutet konkret: Browser zeigen eine Vollbild-Warnung und blockieren die Seite. Besucher koennen die Warnung in den meisten Faellen nicht einfach wegklicken, vor allem nicht bei aktivem HSTS-Header.
Konsequenzen fuer 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 verzoegert zugestellt.
- API-Clients und Mobile-Apps mit Certificate-Pinning brechen ab und muessen unter Umstaenden ein App-Update bekommen.
HSTS, CAA und OCSP-Stapling
Ein gueltiges Zertifikat ist erst der Anfang. Drei zusaetzliche Mechanismen heben TLS-Sicherheit auf Best-Practice-Level:
- HSTS (HTTP Strict Transport Security): Header der Browser zwingt, kuenftig nur noch HTTPS zu nutzen. Empfehlung: max-age=63072000; includeSubDomains; preload (zwei Jahre, alle Subdomains, Preload-Liste). Vorsicht beim Aktivieren, weil ein Fehler nicht zurueckrollbar ist solange max-age noch laeuft.
- CAA (Certification Authority Authorization): DNS-Eintrag der festlegt welche CA Zertifikate fuer 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 fuer Besucher und schont die CA-Infrastruktur. In Apache: SSLUseStapling On, in nginx: ssl_stapling on.
Datenschutz
Der KernelHost SSL-Checker laeuft 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 gepruefte Domain ueber 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.