Was das Web-Modul an Ihrem HTTPS-Setup prüft, warum jeder Check zählt und wie er bewertet wird – inklusive der Bewertungs-Caps, die ein einzelnes schweres Finding auslösen kann.
Jetzt Domain prüfen →
Stand: Juli 2026 · 23 Checks dokumentiert
HTTPS erreichbar (Port 443) #
Jeder Web-Check beginnt mit einer TLS-Verbindung zu Port 443. Kommt keine Verbindung zustande (kein lauschender Dienst, Firewall, DNS zeigt ins Leere), kann keiner der Zertifikats-, Protokoll- oder Cipher-Checks laufen – und auch Besucher erreichen die Seite nicht sicher.
BewertungErscheint nur, wenn die Verbindung fehlschlägt: fail, Gewicht 3. Die übrigen Web-Checks werden dann übersprungen.
BehebungSicherstellen, dass ein Webserver für diesen Namen auf Port 443 lauscht, die Firewall dies zulässt und die DNS-Records auf die richtige Adresse zeigen. Anschließend den Scan erneut ausführen.
Zieladresse blockiert (Scanner-Schutz) #
Die Domain löst auf einen privaten, Loopback- oder anderweitig internen IP-Bereich auf (z. B. RFC 1918). Der Scanner verweigert den Kontakt zu solchen Adressen bewusst: Würde er ihnen folgen, könnten beliebige Domains den Scanner zur Sonde für sein eigenes internes Netz machen (Server-Side Request Forgery). Das ist eine Eigenschaft des DNS-Setups des Scan-Ziels, nicht der Sicherheit Ihres Servers.
BewertungErscheint nur, wenn der Scan aus diesem Grund abgebrochen wird: fail; das Modul ist nicht sinnvoll benotbar. Den Namen auf eine öffentliche Adresse zeigen lassen und erneut scannen, um ein echtes Ergebnis zu erhalten.
BehebungFür eine öffentliche Website muss die Domain auf eine öffentlich routbare IP-Adresse auflösen. Split-Horizon- oder rein interne Namen lassen sich von außen nicht scannen.
Zertifikatskette gültig & vertrauenswürdig #
Browser vertrauen nur Zertifikaten, deren Kette zu einer öffentlich anerkannten Zertifizierungsstelle (CA) führt. Ein selbstsigniertes Zertifikat oder eines von einer unbekannten CA löst eine Sicherheitswarnung aus. Die Kette wird gegen einen kombinierten, aktuellen Root-Store validiert (Betriebssystem + Node-Bundle + die CCADB/Mozilla-TLS-Roots, Roots mit entzogenem Vertrauen ausgeschlossen) – ein veralteter Store würde neue legitime Roots ablehnen oder entfernte fälschlich akzeptieren. Ist die ausgelieferte Kette lediglich unvollständig, wird sie einmalig gegen die öffentlich bekannten CCADB-Intermediates (wöchentlich aktualisiert) nachvalidiert – dieselbe Menge, die Firefox vorlädt und Chrome/Safari per AIA nachladen –, um eine reparierbare Kette von einer wirklich nicht vertrauenswürdigen zu unterscheiden.
Bewertungfail → Sondernote T (Trust); diese überschreibt die Note A+…F vollständig. Gewicht 3. Ausnahme: Eine unvollständige Kette, die mit einem öffentlich bekannten CCADB-Intermediate validiert, wird stattdessen warn (kein T – die Note deckelt „Vollständige Zertifikatskette“ auf B). Der Hostname wird separat geprüft (siehe „passt zum Hostnamen“).
BehebungEin Zertifikat einer öffentlichen CA verwenden (z. B. kostenlos via Let’s Encrypt) und die vollständige Kette ausliefern. ACME automatisiert Ausstellung und Erneuerung.
Zertifikat passt zum Hostnamen #
Der angefragte Hostname muss in den Subject Alternative Names (SAN) des Zertifikats stehen. Andernfalls gibt es keinen Nachweis, dass das Zertifikat zu genau dieser Website gehört.
Bewertungfail → Sondernote M (Mismatch); überschreibt die Buchstabennote. Gewicht 2.
BehebungDen Hostnamen (und ggf. www) in die SAN-Liste aufnehmen oder ein passendes Zertifikat ausstellen lassen.
Restlaufzeit des Zertifikats #
Ein abgelaufenes Zertifikat führt in jedem Browser zu einem harten Fehler – die Seite ist faktisch unerreichbar.
Bewertungpass > 15 Tage; warn ≤ 15 Tage; abgelaufen → fail + Cap F. Gewicht 1.
BehebungDie Erneuerung automatisieren (ACME/Let’s Encrypt, certbot, Caddy). Ein Monitoring der Ablaufdaten einrichten.
Signaturalgorithmus des Zertifikats #
SHA-1 und MD5 sind kollisionsanfällig – damit signierte Zertifikate gelten als fälschbar und werden von Browsern abgelehnt.
Bewertungpass mit SHA-256+; SHA-1/MD5 → fail + Sondernote T. Gewicht 1.
BehebungDas Zertifikat mit SHA-256 (oder stärker) neu ausstellen lassen – bei modernen CAs Standard.
Schlüsselstärke #
Zu kurze Schlüssel können gebrochen werden. Empfohlen: RSA ≥ 2048 Bit oder ECDSA P-256 (≈ RSA 3072).
Bewertungpass mit RSA ≥ 2048 / EC ≥ 256 / Ed25519; RSA < 2048 → warn + Cap B; RSA < 1024 → fail + Cap F. Gewicht 1.
BehebungEinen neuen Schlüssel mit RSA-2048+ oder ECDSA P-256 erzeugen und das Zertifikat neu ausstellen lassen.
Vollständige Zertifikatskette #
Fehlen die Zwischenzertifikate, können viele Clients die Kette nicht aufbauen – obwohl das Zertifikat gültig ist. Browser kompensieren das meist (Firefox lädt alle öffentlich bekannten Intermediates vor, Chrome/Safari holen das fehlende Zertifikat per AIA), strikte Clients wie curl/OpenSSL, die meisten Mailserver und älteres Java scheitern.
Bewertungfail → Cap B, wenn nur das Leaf-Zertifikat ausgeliefert wird oder der Aussteller nicht ermittelt werden kann. Gewicht 1. Der Scanner meldet, ob das fehlende Glied ein öffentlich bekanntes CA-Zertifikat ist (geprüft gegen die ~1.700 CCADB-Intermediates, wöchentlich aktualisiert); wenn nicht, gilt die Kette als nicht vertrauenswürdig (Sondernote T über „gültig & vertrauenswürdig“).
BehebungDie vollständige Kette konfigurieren (Leaf + alle Intermediates). Tools wie „what’s my chain cert“ helfen beim Zusammenstellen.
DANE / TLSA (HTTPS) #
DANE bindet das Website-Zertifikat an einen DNSSEC-gesicherten TLSA-Record unter _443._tcp und härtet TLS damit gegen MITM/Fehlausstellung. Hinweis: Gängige Browser erzwingen DANE für HTTPS nicht; es schützt daher vor allem DANE-fähige Clients und dokumentiert die Zertifikatsabsicht. Bei automatisch erneuerten Zertifikaten übersteht Usage 2 (DANE-TA, Pinning der CA) die Schlüsselrotation, während Usage 3 (DANE-EE, Leaf-SPKI) bei jeder Erneuerung neu veröffentlicht werden muss, sofern der Schlüssel nicht wiederverwendet wird.
Bewertungpass, wenn ein DNSSEC-gesicherter TLSA-Record zur ausgelieferten Kette passt; fail bei Mismatch oder fehlendem DNSSEC (Cap C). Ausnahmen bei PKIX-TA (Usage 0): pinnt es ein gesendetes Intermediate, ist es eine milde warn (kein Cap; DANE-TA ist sauberer); ein Usage-0-Record, der die nicht gesendete Root pinnt, ist info (keine Abwertung; über den Client-Truststore validiert). Ein DANE-TA-Record (Usage 2), dessen einziger Treffer eine gesendete Root über eine Hash-Form (z. B. 2 1 1) ist, gilt weiterhin als bestanden, erhält aber einen Hinweis auf einen 2 0 0-Record (vollständiges Root-Zertifikat im DNS) – eine gesendete cross-signierte Root fällt aus der Kette, sobald ihre Cross-Signatur abläuft; ein Record, der die Root bereits per 2 0 0 pinnt, gilt als robust und besteht sauber. Das Fehlen ist nur info. Gewicht 2 bei Vorhandensein, 0 bei Fehlen.
BehebungOptional, aber empfohlen: DNSSEC aktivieren und einen TLSA-Record unter _443._tcp veröffentlichen (Usage 2 / Selector 1 / Matching 1 mit Pinning der CA ist für ACME-erneuerte Zertifikate am robustesten). Während eines Rollovers den alten und den neuen Record parallel veröffentlichen. Der TLSA-Generator holt das Live-HTTPS-Zertifikat (Port 443) und baut den Record für Usage 2 oder 3.
Gesamtlaufzeit des Zertifikats #
Das CA/Browser Forum begrenzt die maximale Gültigkeit von Leaf-Zertifikaten, und Ballot SC-081 senkt die Obergrenze schrittweise nach Ausstellungsdatum: 398 Tage → 200 Tage (ausgestellt ab 2026-03-15) → 100 Tage (2027) → 47 Tage (2029). Lange Laufzeiten erhöhen das Risiko bei einer Schlüsselkompromittierung; Browser können überlange Zertifikate direkt ablehnen.
Bewertungwarn, wenn die Laufzeit das zum Ausstellungsdatum geltende Limit überschreitet. Gewicht 1.
BehebungKurzlebige Zertifikate mit automatischer Erneuerung (ACME) verwenden – z. B. Let’s Encrypt (90 Tage).
Certificate Transparency (SCT) #
Certificate Transparency protokolliert ausgestellte Zertifikate öffentlich und macht Fehlausstellungen erkennbar. Chrome verlangt gültige SCTs für seit 2018 ausgestellte Zertifikate. Eingebettete SCTs sind bei öffentlichen CAs heute Standard, daher erscheint dieses Finding nur, wenn sie FEHLEN.
BewertungWird nur angezeigt, wenn keine eingebetteten SCTs gefunden werden: warn für Zertifikate mit Ausstellungsdatum nach 2018-04-30 (sie können alternativ via OCSP/TLS ausgeliefert werden), sonst info. Informativ (Gewicht 0).
BehebungDas Zertifikat von einer CA mit CT-Logging beziehen – bei öffentlichen CAs heute Standard (SCTs eingebettet).
Sperrstatus (CRL/OCSP) #
Wird ein Zertifikat kompromittiert und gesperrt, müssen Clients den Sperrstatus prüfen können – via CRL oder OCSP (die Adressen stehen im Zertifikat: CRL Distribution Points / AIA). Mit OCSP-Stapling liefert der Server den signierten Sperrstatus zusätzlich direkt im Handshake mit – schneller und datenschutzfreundlicher, als wenn jeder Client die CA abfragt. HINWEIS: Die Branche zieht sich von OCSP zurück (CA/B-Forum-Ballot SC-063 machte es 2023 optional). Dieser Scanner pflegt eine Liste von CAs, die OCSP eingestellt oder die Einstellung angekündigt haben – derzeit Let's Encrypt (Responder im August 2025 abgeschaltet), Google Trust Services (seit H2 2025 keine OCSP-URLs in neuen Zertifikaten) und HARICA (seit März 2026 keine OCSP-URLs, Responder-Abschaltung bis Mai 2027). Für Zertifikate dieser CAs wird ein fehlendes Staple nie als Server-Mangel gemeldet.
Bewertungpass, wenn CRL- und/oder OCSP-Informationen vorhanden sind (Gewicht 1; mit aktivem OCSP-Stapling Gewicht 2 – ein kleiner Bonus); warn, wenn das Zertifikat keines von beidem enthält. Nur-CRL ist die moderne Norm (Browser nutzen CRL-gespeiste Listen wie CRLite/CRLSets). Eine Stapling-Empfehlung erscheint nur, solange die ausstellende CA OCSP noch betreibt; eine LIVE-OCSP-Abfrage findet nicht statt.
BehebungDas Zertifikat von einer CA beziehen, die CRL- und/oder OCSP-Informationen veröffentlicht (jede öffentlich vertrauenswürdige CA tut das). Nur wenn die CA OCSP weiter betreibt: optional Stapling aktivieren (Caddy: automatisch; nginx: ssl_stapling on).
OCSP Must-Staple #
Trägt das Zertifikat das Must-Staple-Flag, MÜSSEN Server eine OCSP-Antwort per Stapling mitliefern – andernfalls lehnen Browser die Verbindung ab. Das schützt davor, dass Stapling unbemerkt ausfällt.
Bewertungpass, wenn Must-Staple gefordert ist UND Stapling aktiv ist; warn, wenn gefordert, aber kein Stapling aktiv ist. Gewicht 1.
BehebungEntweder Stapling zuverlässig aktivieren oder das Must-Staple-Flag nicht setzen.
TLS-Protokollversionen #
TLS 1.2 und 1.3 sind die sicheren, aktuellen Protokolle – TLS 1.3 ist zusätzlich schneller (1-RTT) und entfernt veraltete Kryptografie. TLS 1.0/1.1 sind formal für überholt erklärt (RFC 8996): Sie setzen auf veraltete Primitive (SHA-1, CBC ohne AEAD), sind für den BEAST-Angriff anfällig und werden seit 2020 von allen großen Browsern abgelehnt. Der Drill-down zeigt die vollständige Angeboten/Deaktiviert-Matrix je Version.
Bewertungpass, wenn nur TLS 1.2/1.3 angeboten werden; warn + Cap A-, wenn TLS 1.3 fehlt; fail, wenn weder 1.2 noch 1.3 ausgehandelt wird, bzw. + Cap B, wenn Legacy-TLS 1.0/1.1 noch aktiv ist. Gewicht 3.
BehebungTLS 1.2 und 1.3 aktivieren (TLS 1.3 erfordert eine aktuelle OpenSSL-/Server-Version) und TLS 1.0/1.1 serverseitig deaktivieren.
HTTP-Versionen (1.1 / 2 / 3) #
Ein gemeinsames Urteil über die Generationen des Anwendungsprotokolls. HTTP/1.1 ist die universelle Basis, die jeder Server spricht – sie trägt kein Signal und wird nur der Vollständigkeit halber aufgeführt. HTTP/2 multiplext viele Requests über eine TLS-Verbindung (ausgehandelt via ALPN h2 im Handshake – zugleich ein Marker für einen modernen TLS-Stack). HTTP/3 läuft über QUIC (UDP 443) und senkt die Latenz weiter; Server kündigen es via Alt-Svc: h3=… an. Neben der Ankündigung wird der QUIC-Endpunkt selbst getestet: Ein Long-Header-Paket mit einer bewusst unbekannten Version erzwingt eine Version-Negotiation-Antwort (RFC 8999/9000 §6), die einen aktiven QUIC-Listener belegt und die unterstützten Versionen offenlegt (v1 = RFC 9000, v2 = RFC 9369) – ganz ohne TLS-Handshake. All das ist Performance/Qualität, keine Sicherheitskontrolle.
Bewertungpass, wenn der Server h2 via ALPN aushandelt (Gewicht 1); nur HTTP/1.1 → nur info (Gewicht 0, keine Abwertung). Der HTTP/3-Status (angekündigt / QUIC-Endpunkt antwortet / beides) wird in Wert und Detail berichtet, ohne die Note zu beeinflussen. Ein Timeout der QUIC-Probe wird nur dann als „Endpunkt schweigt“ interpretiert, wenn Referenz-Probes (gecacht) bestätigen, dass der eigene ausgehende UDP/443-Pfad des Scanners funktioniert; andernfalls wird „nicht prüfbar“ gemeldet.
BehebungHTTP/2 im Webserver aktivieren (z. B. nginx http2 on;, Apache Protocols h2 http/1.1). Für HTTP/3: nginx listen 443 quic plus einen Response-Header Alt-Svc: h3=":443"; ma=86400, UDP 443 öffnen und idealerweise einen HTTPS-DNS-Record mit alpn=h3 veröffentlichen.
Perfect Forward Secrecy #
Mit PFS (ECDHE/DHE) legt ein später kompromittierter Server-Schlüssel aufgezeichneten Datenverkehr nicht nachträglich offen. TLS 1.3 bietet immer PFS.
Bewertungpass bei ECDHE/DHE oder TLS 1.3; sonst warn + Cap B. Gewicht 1.
BehebungCipher Suites mit ECDHE bevorzugen; statischen RSA-Schlüsselaustausch deaktivieren.
Stärke der Diffie-Hellman-Parameter #
Schwache DH-Gruppen (< 2048 Bit) ermöglichen Logjam-Downgrade-Angriffe. ECDHE ist DH-Parametern vorzuziehen.
Bewertungpass ≥ 2048 Bit; warn 1024–2047 (Cap B); < 1024 → fail + Cap F. Gewicht 1.
BehebungDH-Parameter auf ≥ 2048 Bit setzen oder ausschließlich ECDHE verwenden.
Cipher Suites & AEAD #
Schwache Cipher Suites untergraben die Verschlüsselung: RC4 und 3DES sind gebrochen/veraltet, NULL bedeutet keine Verschlüsselung, und Export-/anonyme Suites sind trivial angreifbar. Die AEAD-Verfügbarkeit gehört zum selben Urteil: AEAD-Cipher (AES-GCM, ChaCha20-Poly1305) verschlüsseln und authentifizieren in einem Schritt und vermeiden die Padding-Oracle-Angriffe der älteren CBC-Suites. Der Drill-down listet die angebotenen Suites pro TLS-Version: TLS-≤-1.2-Suites werden iterativ enumeriert, die TLS-1.3-Suites (ein fester Satz von fünf gemäß RFC 8446 Appendix B.4 – alle per Design AEAD mit Forward Secrecy) werden einzeln geprüft. Anmerkung zur Benennung: OpenSSL verwendet für TLS-≤-1.2-Suites eigene Kurznamen (z. B. ECDHE-RSA-AES128-GCM-SHA256), während die TLS-Standards (RFC 2246/4346/5246) und die IANA-Registry dieselbe Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 nennen – der Drill-down zeigt daher beide, sodass die Ergebnisse direkt mit SSL Labs, testssl.sh und Hersteller-Dokumentation vergleichbar sind. Nur für TLS 1.3 hat OpenSSL die RFC-8446-Namen unverändert übernommen.
BewertungNULL/Export/anonym → fail + Cap F; RC4 → Cap B (Cap C bei TLS 1.1+); 3DES bei TLS 1.1+ → Cap C; gar keine AEAD-Suites → warn + Cap B. Server, die nur TLS 1.3 anbieten, erhalten pass mit den angebotenen 1.3-Suites. Gewicht 3.
BehebungNur moderne AEAD-Suites erlauben (AES-GCM, ChaCha20-Poly1305); RC4/3DES/CBC-only/Export/NULL deaktivieren.
Webserver-Backends (pro IP) #
Eine Domain hinter Round-Robin-DNS oder einem CDN löst auf mehrere A/AAAA-Adressen auf. Die detaillierten TLS-Checks oben verbinden sich per Hostname und spiegeln daher nur ein Backend wider (die IP, die der Resolver gerade zurückgegeben hat). Um einen Server zu erwischen, der nur auf einem Teil seiner Adressen fehlkonfiguriert ist, ohne die aufwendige Cipher-Enumeration gegen jede IP zu wiederholen, profiliert dieser Check einen Repräsentanten pro Adressfamilie vollständig (eine IPv4 und eine IPv6 – Zertifikat, TLS-Versionen, komplette Cipher-Enumeration) und bestätigt die übrigen IPs mit einem einzelnen Handshake (Zertifikats-Fingerprint + ausgehandelte Suite). Identische Fingerprints über alle hinweg bedeuten, dass die Backends austauschbar sind (der CDN-/Anycast-Fall); eine Abweichung wird gemeldet. Die Verbindung geht direkt an die IP, sendet aber weiterhin den Hostnamen als SNI. Ein CDN-Anbieter wird benannt, wenn das Reverse-DNS der IPs oder das CNAME des Hosts einen erkennen lässt (z. B. CloudFront, Akamai, Fastly, Cloudflare).
Bewertungpass, wenn alle erreichbaren Backends dasselbe Zertifikat + dieselbe ausgehandelte Suite teilen; warn (Gewicht 1) bei Abweichungen. Adressen, die der Scanner nicht routen kann (z. B. IPv6 ohne IPv6-Egress), werden als „nicht testbar“ markiert und nicht gegen den Server gewertet.
BehebungVon jedem Backend eine identische TLS-Konfiguration und dasselbe Zertifikat ausliefern, damit die Sicherheit, die ein Client bekommt, nicht davon abhängt, welche IP er zufällig erreicht.
Server-Cipher-Präferenz (TLS ≤ 1.2) #
Bestimmt der Server die Cipher-Reihenfolge, kann er stets die stärkste gemeinsame Suite durchsetzen. Folgt er dem Client, kann ein schwacher Client eine schwächere Suite erzwingen – aber nur, wenn überhaupt schwächere Suites angeboten werden. Moderne Stacks (Go/Caddy, BoringSSL) folgen bewusst dem Client, damit Geräte ohne AES-Hardware ChaCha20 wählen können; Go hat die Server-Präferenz-Option komplett entfernt. Geltungsbereich: Der Schalter (nginx ssl_prefer_server_ciphers, OpenSSL SSL_OP_CIPHER_SERVER_PREFERENCE) regelt nur TLS ≤ 1.2. Für TLS 1.3 gilt er NICHT – dort wählt der Server die Suite immer aus seiner eigenen Reihenfolge –, weshalb dieser Check als „TLS ≤ 1.2“ gekennzeichnet ist. Die Probe läuft mit TLS 1.2 (repräsentativ, da es sich um eine einzelne serverweite Einstellung handelt, die 1.0/1.1/1.2 abdeckt).
Bewertungpass, wenn der Server seine eigene Reihenfolge durchsetzt; eine vom Client entschiedene Reihenfolge bei durchgehend starkem Suite-Satz (AEAD + Forward Secrecy, nichts Schwaches) ist unbedenklich (hellgrüner Check, ohne Benotung); warn nur, wenn der Client entscheidet UND schwächere Suites angeboten werden. Nicht anwendbar auf TLS 1.3 (dort entscheidet immer der Server).
BehebungNur nötig, wenn schwächere Suites angeboten werden: „honor server cipher order“ aktivieren (nginx: ssl_prefer_server_ciphers on) – oder besser die schwachen Suites entfernen.
Hash-Funktion für den Schlüsselaustausch #
Der Server signiert den ephemeren Schlüsselaustausch (ServerKeyExchange) jeder Forward-Secrecy-Suite (ECDHE/DHE). Welcher Hash verwendet wird, hängt von der TLS-Version ab. TLS 1.0/1.1 haben keine signature_algorithms-Aushandlung, der Hash ist also durch das Protokoll festgelegt – RSA-Suites nutzen MD5+SHA-1, ECDSA nutzt SHA-1 –, sodass jede Forward-Secrecy-Suite auf diesen Versionen auf dem gebrochenen SHA-1 beruht, was sich nicht wegkonfigurieren lässt. TLS 1.2 handelt den Hash aus. Entscheidend ist der Hash, den ein echter Client tatsächlich bekommt: Browser bieten SHA-256 und stärker an und niemals SHA-1/SHA-224 – ein Server, der irgendeinen modernen Hash unterstützt, signiert für sie also stark. Wir prüfen daher, ob der Server überhaupt mit SHA-256+ signieren kann; nur wenn nicht (er endet bei SHA-224 oder SHA-1), wird ein normaler Client herabgestuft. Ein Server, der SHA-224 lediglich toleriert, wenn ein Client nichts anderes anbietet (fast alle tun das, z. B. CloudFront/Amazon), wird nicht bemängelt – das wäre ein False Positive. TLS 1.3 erzwingt SHA-256+ per Design. Der Drill-down listet pro TLS-Version die genauen Cipher Suites, deren Schlüsselaustausch mit einem schwachen Hash signiert wird. Statische RSA-Suites (TLS_RSA_*) senden kein ServerKeyExchange und sind nicht betroffen.
BewertungGeprüft pro angebotener TLS-Version. pass, wenn normale Clients SHA-256+ bekommen; warn (Gewicht 1), wenn TLS 1.2 nicht mit SHA-256+ signieren kann und bei SHA-224 endet; fail (Gewicht 2), wenn SHA-1 verwendet wird – automatisch bei jeder Forward-Secrecy-Suite über TLS 1.0/1.1, oder bei TLS 1.2, wenn der Server keinen stärkeren Hash als SHA-1 anbietet.
BehebungTLS 1.0 und TLS 1.1 deaktivieren (deren SHA-1-Signaturen des Schlüsselaustauschs sind nicht konfigurierbar). Bei TLS 1.2 die Server-Signaturalgorithmen auf SHA-256+ beschränken, z. B. nginx/OpenSSL: ssl_conf_command SignatureAlgorithms ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512 (RSA-Zertifikate: RSA-PSS+SHA256/384/512 ergänzen).
Client-Kompatibilität (Simulation) #
Eine vereinfachte Handshake-Simulation zeigt, welche Referenz-Clients (Browser, Android, Java, OpenSSL) sich verbinden können. Simuliert werden nur Clients, deren OS/Runtime noch Sicherheitsupdates erhält – End-of-Life-Clients (Android ≤7, IE 11, Java 8, OpenSSL 1.0.x) sind bewusst ausgeschlossen, weil ihre Kompatibilität keine Aussagekraft für eine aktuelle TLS-Konfiguration hat.
Bewertungwarn, wenn sich IRGENDEIN simulierter Referenz-Client (Chrome/Firefox/Safari aktuell, Android 14, Java 17, OpenSSL 3.x) nicht verbinden kann; sonst pass. Gewicht 1.
BehebungScheitert ein unterstützter Client, ist die TLS-Konfiguration zu restriktiv oder fehlerhaft – Protokolle/Cipher prüfen.
HTTP-zu-HTTPS-Redirect #
Ruft jemand die Seite über http:// auf, sollte sie sofort auf https:// umleiten – sonst startet die Sitzung unverschlüsselt und kann manipuliert werden.
Bewertungpass bei 301/302 auf eine https-URL; fail, wenn HTTP ohne Redirect ausgeliefert wird; skip, wenn Port 80 geschlossen ist. Gewicht 2.
BehebungAlle HTTP-Anfragen per 301 dauerhaft auf HTTPS umleiten (zusätzlich HSTS setzen).