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: September 2026 · 25 Checks dokumentiert
Website konfiguriert (A/AAAA-Records) #
Die Module Website und HTTP-Security-Header prüfen eine laufende Website. Hat weder die Domain selbst noch www A- oder AAAA-Records, gibt es keine Website, zu der eine Verbindung aufgebaut werden könnte – ein völlig normales Setup für Domains, die nur für E-Mail genutzt werden.
BewertungErscheint nur, wenn die Domain selbst existiert (NOERROR), aber keine A/AAAA-Records hat, www ebenfalls keine hat (eindeutige NOERROR/NXDOMAIN-Antworten) und auf keinem der beiden Namen ein CNAME konfiguriert ist: skip; das Modul wird als nicht anwendbar gemeldet, statt mit F benotet zu werden. Alles andere – ein DNS-Fehler (z. B. eine kaputte DNSSEC-Kette), eine nicht existierende Domain oder ein ins Leere zeigender CNAME – lässt die regulären Checks laufen, damit eine defekte Website weiterhin als nicht erreichbar erscheint. Vor der Behauptung wird der Name zusätzlich nach einem HTTPS-Record gefragt: RFC 9460 erlaubt es, einen Dienst über einen AliasMode-Record ganz ohne eigene Adressrecords zu erreichen. Wird einer gefunden, meldet das Modul skip und nicht gemessen und wird NICHT als nicht anwendbar geführt – die Seite existiert, sie wurde hier nur nicht geprüft; antwortet diese Abfrage nicht schlüssig, wird in keine Richtung etwas behauptet.
BehebungNichts zu tun, wenn die Domain bewusst nur für E-Mail genutzt wird. Soll eine Website existieren, A/AAAA-Records für die Domain oder www anlegen und den Scan erneut ausführen.
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. Hat weder die Domain noch www überhaupt A/AAAA-Records, wird das Modul gar nicht benotet – siehe „Website konfiguriert (A/AAAA-Records)“.
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, Gewicht 3 – als einziges bewertungsrelevantes Finding ergibt das die Modulnote F. Dieses F beschreibt unsere Weigerung, eine interne Adresse zu kontaktieren, nicht die Sicherheit Ihres Servers. 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 Root-Store validiert (Betriebssystem + Node-Bundle + der wöchentliche CCADB/Mozilla-TLS-Stand). Dieser Store ist eine VEREINIGUNG: Er addiert nur und entfernt nie – eine Root, der Mozilla das Vertrauen entzogen hat, bleibt hier also vertrauenswürdig, solange Betriebssystem oder Node-Bundle sie weiterhin mitliefern (32 solcher Anker bei der letzten Messung im August 2026). Der Scan prüft deshalb zusätzlich, ob der Anker, in dem die Kette endet, noch zur aktuellen Mozilla/CCADB-TLS-Menge gehört, und warnt, wenn nicht – dreiwertig, damit ein fehlender oder unplausibel kleiner Stand nie zur Behauptung „Anker veraltet“ wird. Mozilla kennt eine ZWEITE, datierte Form des Vertrauensentzugs, die eine Mengenzugehörigkeit nicht ausdrücken kann: Eine Root kann in der Menge bleiben, während NSS jedes Endzertifikat ablehnt, dessen notBefore nach einem Stichtag liegt (CKA_NSS_SERVER_DISTRUST_AFTER, von CCADB als „Distrust for TLS After Date“ veröffentlicht). Diese Stichtage sind deshalb ein eigener wöchentlicher Datensatz, und die Prüfung liest ihn nach derselben Regel: Ein fehlender oder veralteter Stand behauptet nichts, ein Stand, der einen Stichtag nennt, belegt ihn weiterhin – ein Eintrag wird durch Alter nicht falsch, eine Abwesenheit schon. 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 per AIA nachlädt –, 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 1: 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). Ausnahme 2: Eine Kette, die zwar vertrauenswürdig ist, aber in einer Root endet, die nicht mehr zur aktuellen Mozilla/CCADB-TLS-Menge gehört, ist warn ohne Cap – das Zertifikat selbst ist in Ordnung, aber der Anker gehört nicht mehr zur aktuellen TLS-Root-Menge von Mozilla, Firefox wird es also nicht mehr annehmen (NSS-Releases hinken CCADB hinterher, der genaue Zeitpunkt ist nicht unsere Aussage). Ausnahme 3: Eine Kette, deren Root zwar noch in der Menge steht, aber einen Mozilla-Stichtag trägt, hinter dem das notBefore dieses Zertifikats liegt, ist ebenfalls warn ohne Cap – bewusst dieselbe Note wie Ausnahme 2, denn für dieses Zertifikat bedeuten beide dasselbe: Firefox weist es ab, und den engeren Fall härter zu benoten als den breiteren wäre der Widerspruch. Liegt der Stichtag vor, das Zertifikat aber davor, bleibt die Note pass und es kommt nur ein Satz hinzu – ausgeliefert ist nichts Defektes, die nächste Erneuerung unter dieser Root wird aber abgewiesen. Alle drei Urteile sind dreiwertig und werden ohne brauchbaren Datensatz nie gefällt. 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.
Zertifikatsprüfungen #
Ein Platzhalter, der nur erscheint, wenn der TLS-Handshake zustande kam, ohne dass der Server ein Zertifikat vorgelegt hat. Alles, was die Zertifikats-Findings beschreiben – Hostname-Übereinstimmung, Gültigkeit, Signaturalgorithmus, Schlüsselstärke, Kettenvollständigkeit, Sperrinformationen – setzt ein vorhandenes Zertifikat voraus. Statt sechs Urteile über etwas zu fällen, das niemand gesehen hat, meldet das Modul einen einzigen Eintrag, der genau das sagt. Es gibt zwei Wege hierher, und sie werden getrennt gehalten: Die Gegenseite hat wirklich keines gesendet, oder dieser Scanner hat eine TLS-Sitzung wiederaufgenommen und das Zertifikat deshalb nie erneut gesehen. Ein Server lässt die Certificate-Nachricht berechtigterweise weg, sobald der Schlüsselaustausch nicht zertifikatsbasiert ist — RFC 8446 §4.4.2 verlangt sie für jede dort definierte Methode „except PSK“ —, und unter TLS 1.3 IST eine Wiederaufnahme genau so ein PSK-Handshake (§2.2); deshalb sieht der zweite Fall auf der Leitung gleich aus. Was Browser nicht anbieten, ist ein ANONYMER Schlüsselaustausch: BoringSSL definiert überhaupt keine anonyme Cipher-Suite, und die konfigurierbare Suite-Tabelle in NSS trägt weder einen anonymen noch einen PSK-Eintrag für TLS 1.2.
Bewertungskip, Gewicht 7 – das zusammengefasste Gewicht der sechs Zertifikats-Findings, für die er einsteht. Ein skip verlässt Zähler und Nenner gleichermaßen und zählt damit nie gegen die Domain. Als nicht gemessen wird er nur im Wiederaufnahme-Fall geführt, denn das ist unser blinder Fleck; hat der Server tatsächlich kein Zertifikat vorgelegt, sind die Prüfungen nicht anwendbar statt ungemessen, und cert-trust trägt dieses Urteil mit fail + Cap T.
BehebungDen Server mit einem Zertifikat einer öffentlich vertrauenswürdigen CA konfigurieren. Ist das ohne Konfigurationsänderung aufgetreten, den Scan erneut ausführen – eine wiederaufgenommene Sitzung kann das Zertifikat vor einer einzelnen Messung verbergen.
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. Ein Zertifikat OHNE Subject Alternative Name, das nur über den veralteten commonName passt, ist warn (kein Cap): Chrome, Firefox und Safari ignorieren den CN allesamt, ein solches Zertifikat fällt beim Namensabgleich also rundweg durch — Chromium gibt false zurück, sobald beide SAN-Listen leer sind (X509Certificate::VerifyHostname), mozilla::pkix fährt eine Policy, die nie in den Subject-Namen zurückfällt, und Apple vertraut DNS-Namen im CommonName seit iOS 13 / macOS 10.15 nicht mehr. Ein solches Zertifikat auszustellen verbieten zusätzlich die CA/Browser-Forum Baseline Requirements §7.1.2.7.12 — das ist eine Regel für CAs und sagt nichts über Client-Verhalten; ein SAN, der nur Nicht-dNSName-Einträge trägt (etwa eine iPAddress), wird genau so gemeldet und nicht als fehlender SAN. Für Wildcards gilt RFC 9525 §6.3: Das * muss das vollständige linkeste Label sein, und es darf nur eines geben, sonst ist der Eintrag ungültig und wird ignoriert – das Finding benennt einen solchen Eintrag, statt nur zu sagen, der Host stehe nicht im SAN. Über einen ICANN-Public-Suffix hinweg wird eine Wildcard nie gematcht (CA/Browser-Forum-BR §3.2.2.6).
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, solange mehr Zeit bleibt als die Erneuerungsschwelle; warn ab dieser Schwelle abwärts; abgelaufen → fail + Cap F; noch nicht gültig (validFrom in der Zukunft) → fail ohne Cap; kein brauchbares Ablaufdatum → skip. Gewicht 1. Die Schwelle richtet sich nach der Laufzeit des Zertifikats selbst – ein Viertel der Gesamtlaufzeit, höchstens 15 Tage (15 Tage bei einem 90-Tage-Zertifikat, 12 bei einem 47-Tage-Zertifikat, 2 bei einem 6-Tage-Kurzläufer); eine feste 15-Tage-Grenze hieße bei kurzlebigen Zertifikaten „immer warnen“.
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. Geprüft werden das Leaf UND die Intermediate-CA-Zertifikate der ausgelieferten Kette – ein schwacher Hash irgendwo darin ergibt dasselbe fail + T, und das Finding benennt dann das Intermediate. Eine selbstsignierte Root bleibt bewusst ausgenommen: Ein Trust Anchor wird über seine Identität validiert, nicht über die eigene Signatur. Dasselbe gilt für ein selbstsigniertes LEAF – RFC 5280 §6.1 hält einen selbstsignierten Anker aus dem Zertifizierungspfad heraus, diese Signatur prüft also niemand; das Finding meldet dann info ohne Deckel, und cert-trust hat das Modul aus dem eigentlichen Grund längst auf T gedeckelt. Das CA/Browser-Forum missbilligt das nicht nur: BR §7.1.3.2.1 verpflichtet die ausstellende CA, jedes nicht abgelaufene SHA-1-signierte Sub-CA-Zertifikat vor dem 15.09.2026 zu widerrufen (Ballot SC-097).
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). Die Größe ist nicht der einzige Mangel: Manche Schlüssel sind durch ihre ERZEUGUNG gebrochen – der ROCA-Fehler in Infineons RSA-Schlüsselerzeugungs-Bibliothek (CVE-2017-15361), ausgeliefert in TPM-Firmware, Smartcards und Security-Tokens dieses Herstellers, und RSA-Moduln, deren beide Primzahlen nah beieinanderliegen (Fermat-faktorisierbar). Ein Modulus mit nahen Primzahlen ist bei jeder Schlüssellänge faktorisierbar; ein ROCA-Schlüssel ist es praktisch in den von den Forschern genannten Bändern (512–704, 992–1216 und 1984–2144 Bit – ein 4096-Bit-Schlüssel nicht). Die Baseline Requirements (§6.1.1.3, Ballot SC-073) verpflichten CAs, beide Sorten ausnahmslos abzulehnen.
Bewertungpass mit RSA ≥ 2048 / EC ≥ 256 / Ed25519 / Ed448; RSA < 2048 → warn + Cap B; RSA < 1024 → fail + Cap F; jeder andere Schlüssel unter dem Minimum (z. B. EC < 256) → fail ohne Cap; ein Schlüsseltyp, dessen Größe sich nicht bestimmen lässt → info mit Begründung, nie pass. Gewicht 1. Über die Größe hinaus wird der RSA-Modulus auf bekannt gebrochenen INHALT geprüft (BR §6.1.1.3 / Ballot SC-073): ROCA-Fingerprint (CVE-2017-15361) und Fermat-faktorisierbare nahe Primzahlen. Ein Treffer ist bei jeder Schlüssellänge fail + Cap F – die Baseline Requirements verbieten diese Schlüssel ohne Längenbedingung, Zertifikat UND Schlüssel müssen ersetzt werden. Diese Prüfung hat selbst eine Grenze: Sie endet bei 8192 Bit, wo allein der Fermat-Test Sekunden blockierter Rechenzeit kosten würde. Darüber sagt das Finding, dass der Modulus nicht geprüft wurde, statt ihn als sauber zu melden, und die Note bleibt davon unberührt – unsere eigene Grenze kostet eine Domain nie einen Punkt.
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. Chrome holt das fehlende Zertifikat über AIA nach; Firefox betreibt kein AIA-Nachladen und nimmt es aus einer vorgeladenen Menge; curl/OpenSSL tun beides nicht, die meisten Mailserver ebenso wenig, und Java hat das AIA-caIssuers-Nachladen in aktuellen Versionen per DEFAULT abgeschaltet (com.sun.security.enableAIAcaIssuers), nicht nur in alten. Safari wird hier nicht genannt: Apple veröffentlicht den Code nicht, der das entscheiden würde. Browser kompensieren das meist (Firefox lädt alle öffentlich bekannten Intermediates vor, Chrome holt 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) – ebenso ein Usage-0-Record, der eine cross-signierte Root trifft, die der Server MITSENDET; das ist ein gültiger Root-Pin. Records mit unbekannter Usage, unbekanntem Selector oder unbekanntem Matching-Typ sind unbrauchbar (RFC 6698 §4.1): DANE-Clients ignorieren sie, für sich allein sind sie daher warn ohne Cap und nie ein harter Mismatch. 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. Kommt unsere eigene TLSA-Abfrage zu keiner schlüssigen Antwort – sie schlug ganz fehl, oder alle Resolver meldeten SERVFAIL –, meldet das Finding „nicht ermittelt“ (ebenfalls info) und gibt bewusst keine Empfehlung – eine unbeantwortete Abfrage ist nicht die Aussage „diese Domain hat keine TLSA-Records“. Gewicht 2 bei vorhandenen Records, 0 bei fehlenden oder nicht ermittelten.
BehebungOptional, aber empfohlen: DNSSEC aktivieren und einen TLSA-Record unter _443._tcp veröffentlichen. Usage 2 (DANE-TA, Pinning der CA) übersteht ACME-Erneuerungen; zum Selector sagt RFC 7671 §5.2.1, DANE-TA-Publisher „SHOULD publish records with a selector of Cert(0)“ – 2 0 1 ist damit die Form der Wahl. 2 1 1 bleibt zulässig und übersteht zusätzlich eine Neuausstellung mit gleichem CA-Schlüssel, aber bei SPKI(1) werden „elements of the TA certificate other than the public key“ veränderlich – Path-Length- und Name-Constraints fallen aus dem Pin. Während eines Rollovers den alten und den neuen Record mindestens zwei TTLs der TLSA-RRset parallel veröffentlichen (RFC 7671 §8.1). 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.
Bewertungfail + Sondernote T, sobald die Laufzeit über dem liegt, was ein Browser durchsetzt – denn das ist ein laufender Ausfall. Chrome folgt derselben SC-081-Leiter wie das CA/Browser Forum – 200 Tage ab 2026-03-15, 100 ab 2027-03-15, 47 ab 2029-03-15, davor 398 – und zeigt darüber eine ganzseitige Fehlermeldung; Apple veröffentlicht nur die 398-Tage-Regel, Safari wird deshalb allein für diese Schwelle genannt, und Firefox setzt diese Grenzen auf dem gewöhnlichen HTTPS-Pfad überhaupt nicht durch: NSSCertDBTrustDomain::CheckValidityIsAcceptable liefert dort unbedingt Erfolg zurück (am 2026-08-28 aus mozilla-central gelesen), die Verbindung kommt also zustande. Eine 14-Tage-Grenze gibt es in Firefox für WebTransport-serverCertificateHashes, das ist aber ein anderer Pfad und keine TLS-Server-Authentifizierung. warn (kein Cap) bleibt für den einen Fall, in dem das Zertifikat die Ausstellungsregel bricht, ohne blockiert zu werden: Chrome rechnet die Spanne exklusiv, ein Zertifikat genau auf der Grenze ist nach der inklusiven Zählung ein Verstoß und wird dort trotzdem akzeptiert. Apple definiert die Gültigkeitsdauer für seine eigene 398-Tage-Regel inklusiv (RFC 5280 §4.1.2.5), in Safari muss dasselbe Zertifikat also nicht der mildere Fall sein. Gewicht 1. Die 398-Tage-Prüfung rechnet die Differenz der beiden Daten exklusiv; ein Zertifikat, das im Bericht mit „399 Tage“ erscheint (inklusiv gezählt, wie es die Baseline Requirements tun), kann daher noch der mildere Fall sein.
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; Firefox und Safari erzwingen Certificate Transparency ebenfalls – ein öffentlich vertrauenswürdiges Zertifikat ohne SCTs wird also von allen dreien abgelehnt (Firefox: security.pki.certificate_transparency.mode steht per Default auf 2 = durchsetzen, am 2026-08-28 aus mozilla-central gelesen). 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, sonst info. Informativ (Gewicht 0). SCTs per OCSP auszuliefern ist keine gangbare Alternative mehr: Chrome akzeptiert seit Version 148 keine SCTs mehr aus gestapelten OCSP-Antworten, und OCSP ist für CAs optional geworden (CA/Browser-Forum-Ballot SC-063, wirksam 2024-03-15) – Let’s Encrypt hat seine Responder im August 2025 ganz abgeschaltet und Google Trust Services veröffentlicht keine OCSP-URL, während die meisten anderen öffentlichen CAs weiterhin eine betreiben; es ist also eine Verschiebung und keine Abschaltung. Eingebettete SCTs sind praktisch der einzige Weg, den CAs ausliefern – gemessen am 2026-08-28 über 16 Hosts aus 12 ausstellenden Organisationen: 16 von 16 Leaf-Zertifikaten tragen die eingebettete SCT-Extension, 0 von 8 geprobten Hosts lieferten SCTs über die TLS-Extension – die TLS-Extension funktioniert weiterhin, muss aber am Server konfiguriert werden.
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); ebenso pass für ein kurzlebiges Zertifikat, das keines von beidem trägt – die Baseline Requirements nehmen solche Zertifikate von den Sperrinformationen aus (Gesamtlaufzeit ≤ 7 Tage bei Ausstellung ab dem 15.03.2026, davor ≤ 10 Tage), weil die kurze Laufzeit die Sperrung ersetzt; warn nur, wenn ein normales Zertifikat keines von beidem enthält. Nur-CRL ist heute die Norm, die beiden Browser-Mechanismen reichen aber unterschiedlich weit: Firefox fasst die CRLs der CAs zu CRLite zusammen (Standard seit Firefox 137, deckt die CT-geloggten Sperrungen ab), während Chromes CRLSets in erster Linie eine Notfall-Sperrliste sind, die eine Teilmenge der eingesammelten Sperrungen trägt – Chrome selbst nennt das „die meisten sicherheitsrelevanten“ Sperrungen und führt gar keine Online-Abfragen per OCSP oder CRL durch. Eine Stapling-Empfehlung erscheint nur, solange die ausstellende CA OCSP noch betreibt; eine LIVE-OCSP-Abfrage findet nicht statt. Die mitgelieferten Bytes werden auf ihren responseStatus nach RFC 6960 §4.2.1 gelesen, und nur successful zählt als Stapling: Eine Antwort mit tryLater oder unauthorized behandeln Clients genau wie gar kein Stapling, sie bringt also weder das Bonusgewicht noch die Stapling-Formulierung – das Finding benennt den Status und rät stattdessen dazu, die Responder-Verbindung zu reparieren.
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, muss der Server eine OCSP-Antwort per Stapling im Handshake mitliefern – andernfalls verweigert Firefox die Verbindung. Firefox ist der einzige gängige Browser, der das Flag durchsetzt (gegen mozilla-central geprüft im August 2026: security.ssl.enable_ocsp_must_staple steht standardmäßig auf true). Chrome setzt es nicht um – weder Chromiums Zertifikatsprüfer noch der Pfadbau von BoringSSL kennt die TLS-Feature-Extension (OID 1.3.6.1.5.5.7.1.24) –, und Apples veröffentlichter Trust-Evaluation-Code kennt sie ebenfalls nicht: trustd nimmt gestapelte OCSP-Antworten sehr wohl entgegen, aber die geschlossene Liste bekannter Extensions im Zertifikats-Parser enthält keinen TLS-Feature-Eintrag — im veröffentlichten Code kann das Flag also nichts durchsetzen. Safaris eigener TLS-Stack ist nicht quelloffen; das ist damit eine Lesart von Apples Code und keine Messung am Browser. Das schützt davor, dass Stapling unbemerkt ausfällt – bedeutet aber auch, dass ein Must-Staple-Zertifikat mit defektem Stapling Firefox-Nutzer vollständig aussperrt.
Bewertungpass, wenn Must-Staple gefordert ist UND Stapling aktiv ist; fail, wenn das fehlende Stapling in einem zweiten, getrennten Handshake bestätigt wurde – Firefox verweigert dann die Verbindung; warn, wenn im ersten Handshake kein Staple kam, der bestätigende zweite Handshake aber nicht zustande kam und ein Einzelfall nicht auszuschließen 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); TLS 1.0 ist zusätzlich für den BEAST-Angriff anfällig, dessen Ursache – der vorhersagbare CBC-Initialisierungsvektor – in TLS 1.1 durch einen expliziten IV gerade behoben wurde; und beide werden seit 2020 von allen großen Browsern abgelehnt. Der Drill-down zeigt die vollständige Angeboten/Deaktiviert-Matrix je Version.
Bewertungpass nur, wenn TLS 1.2/1.3 angeboten werden UND jede Version tatsächlich gemessen wurde; warn + Cap A-, wenn TLS 1.3 messbar fehlt; fail, wenn weder 1.2 noch 1.3 ausgehandelt wird, bzw. + Cap B, wenn Legacy-TLS 1.0/1.1 messbar noch aktiv ist. Gewicht 3. Jede Versionsprobe ist dreiwertig: Eine Version ohne Antwort gilt als „nicht ermittelt“ – weder Entwarnung noch Abwertung. Sie verhindert das Urteil „nur moderne Versionen“ (warn, kein Cap) und löst nie einen Cap oder einen „nicht angeboten“-Satz aus. Eine Version, die der Haupt-Handshake nachweislich ausgehandelt hat, gilt immer als angeboten, auch wenn ihre eigene Probe fehlschlug.
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 Basis, die nahezu jeder Server noch spricht – dieser Scanner prüft sie nicht gesondert, sie trägt deshalb 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 lädt zu einer Version-Negotiation-Antwort ein (RFC 8999/9000 §6). Eine Version-Negotiation-Antwort belegt einen aktiven QUIC-Listener und legt die unterstützten Versionen offen (v1 = RFC 9000, v2 = RFC 9369) – ganz ohne TLS-Handshake. Jedes ANDERE Datagramm von diesem Endpunkt belegt nur, dass auf UDP 443 etwas lauscht, und genau das schreibt der Bericht dann auch, statt QUIC zu nennen; zusätzlich wird die Antwort gegen ihre Quelladresse und ihren Quellport geprüft (RFC 9000 §9 verlangt von einem Client, Pakete von unbekannter Serveradresse zu verwerfen). Schweigen belegt nichts: RFC 8999 §6 sagt, ein Server „might“ auf eine solche Probe antworten; Rate-Limiting, Anti-Amplification-Grenzen oder eine Firewall sind legitime Gründe zu schweigen. 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 ab 1.25.1 http2 on;, ältere nginx listen 443 ssl http2;, 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 privater Zertifikatsschlüssel aufgezeichneten Datenverkehr nicht nachträglich offen — er ist dort nur ein Signaturschlüssel. Das gilt nicht für jedes serverseitige Geheimnis: Ein TLS-1.2-Session-Ticket trägt das Master Secret, verschlüsselt unter einem langlebigen Ticket-Schlüssel (RFC 5077), und eine TLS-1.3-Wiederaufnahme ohne (EC)DHE (psk_ke) sowie 0-RTT-Daten sind überhaupt nicht forward secret (RFC 8446, App. E.1). TLS 1.3 bietet immer PFS. Der Check beantwortet zwei Fragen, nicht eine: Hat UNSERE Verbindung Forward Secrecy – und kann IRGENDEIN Client ohne sie landen? Die zweite betrifft den gesamten Satz der noch angebotenen TLS-≤-1.2-Suites; ein über TLS 1.3 erreichter Server kann daher trotzdem wegen weiterhin aktiver Static-RSA-Suites bemängelt werden.
Bewertungpass, wenn die eigene Verbindung ECDHE/DHE oder TLS 1.3 nutzt UND keine angebotene Suite ohne Forward Secrecy ist; warn ohne Cap, wenn die Verbindung zwar forward-secret ist, der Server aber zusätzlich TLS-≤-1.2-Suites ohne Forward Secrecy anbietet (statisches RSA) – ein Client, der nur diese anbietet, bekommt eine Verbindung, deren mitgeschnittener Verkehr sich später entschlüsseln lässt, falls der Serverschlüssel abhandenkommt, und RFC 9325 §4.1 verlangt, dass Server Forward-Secret-Suites bevorzugen; warn + Cap B nur, wenn die eigene Verbindung gar keinen ephemeren Schlüsselaustausch nutzt. Gewicht 1. Eine bereits gesehene Suite zählt auch bei abgebrochener Enumeration – die Gegenrichtung ist aber eine ABWESENHEITS-Aussage und braucht eine vollständige Liste. Brach die Enumeration ab, besteht das Finding weiterhin auf seiner gemessenen Hälfte und sagt im Klartext, dass dies keine Aussage über jede vom Server angebotene Suite ist. Die Note bleibt dort bewusst unangetastet: Gewicht 1 aus dem Nenner zu nehmen ließe die Note bei WENIGER Messung STEIGEN.
BehebungCipher Suites mit ECDHE bevorzugen; statischen RSA-Schlüsselaustausch deaktivieren.
Stärke der Diffie-Hellman-Parameter #
Schwache DH-Gruppen sind auf zwei verschiedenen Wegen angreifbar: Der Logjam-Downgrade zwingt eine Verbindung auf 512-Bit-Export-DH herunter (sofern Export-Suites angeboten werden), während 1024-Bit-Gruppen – in der Praxis eine Handvoll gemeinsam genutzter Standardprimzahlen – in Reichweite einer einmaligen Vorberechnung durch einen finanzstarken Angreifer liegen, die anschließend aufgezeichneten Verkehr passiv entschlüsselt. 2048 Bit schließt beides; mit ECDHE stellt sich die Frage gar nicht.
Bewertungpass ≥ 2048 Bit; warn 1024–2047; < 1024 → fail. Gewicht 1. Ein Server, der DHE nur als FALLBACK anbietet, ist ebenfalls erfasst: Die Gruppe stammt aus der Cipher-Enumeration, die diesen Handshake ohnehin gefahren hat, das kostet also keine zusätzliche Verbindung. Eine solche Gruppe wird mit demselben Status gemeldet, aber OHNE Notendeckel – sie erreicht nur Clients, die nichts Besseres anbieten, dieselbe Linie, die tls-pfs für daneben angebotene Static-RSA-Suites zieht – und das Finding sagt, ob die Gruppe ausgehandelt oder nur angeboten wurde. Zu den Notendeckeln, ehrlich gesagt: Ein Deckel (B unter 2048, F unter 1024) ist der Gruppe vorbehalten, die unsere eigene Verbindung tatsächlich ausgehandelt hat — und die Messung zeigt, dass diese Kombination derzeit gar nicht vorkommen kann. Der Haupt-Handshake dieses Scanners läuft auf der Standard-Sicherheitsstufe seiner TLS-Bibliothek und lehnt eine DH-Gruppe unter 2048 Bit rundweg ab; eine schwache Gruppe ist damit nur über die Cipher-Enumeration zu sehen, die diese Stufe absichtlich senkt — also ausschließlich im ungedeckelten „angeboten“-Zweig. Die beiden Cap-Buchstaben sind deshalb ruhend, nicht falsch: Sie beschreiben die Regel, und es sind unsere eigenen Probe-Einstellungen, die sie am Auslösen hindern. Wo das zutrifft, sagt das Finding es, statt zu suggerieren, der Server habe lediglich eine andere Suite bevorzugt.
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 9846 Appendix B.4 – bauartbedingt alle AEAD; eine TLS-1.3-Suite benennt nur AEAD und Hash, die Forward Secrecy kommt aus dem (EC)DHE-Schlüsselaustausch jedes vollen Handshakes, nicht aus der Suite) 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 mit RFC 2246/4346/5246 eingeführte Namenskonvention und die IANA-Registry dieselbe Suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 nennen (vergeben durch RFC 5289) – 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-Namen unverändert übernommen.
BewertungNULL/Export/anonym → fail + Cap F; einfaches DES (56-Bit-Schlüssel) → Cap C; 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. Das Urteil ist bewusst asymmetrisch: Eine GEFUNDENE schwache Suite bleibt fail, auch wenn die Enumeration vorzeitig abbrach – die ABWESENHEIT schwacher Suites verlangt dagegen eine vollständige Liste: Eine durch unser Zeitbudget oder unseren Deckel abgebrochene Enumeration meldet info (keine Aussage) statt eines grünen pass; eine durch eine fehlgeschlagene Probe von UNS abgebrochene meldet skip und weist ihre 3 Punkte als nicht gemessen aus, sodass der Bericht sagt, wie viel von der Prüfung die Note abdeckt. Ein Server, dessen TLS-≤-1.2-Unterstützung sich gar nicht feststellen ließ, meldet ebenfalls skip. Schwache Familien, die der TLS-Build dieses Scanners gar nicht anbieten kann (derzeit RC4, 3DES, Export und einfaches DES), werden im Finding als ungeprüft benannt statt als abwesend: Ein Server kann nur wählen, was unser ClientHello trägt.
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). Diese beiden Abfragen sind kosmetisch – kein Teil dieser Bewertung liest das Label –, sie laufen deshalb mit einem kurzen Timeout und entfallen ganz, sobald das Zeitbudget des Moduls aufgebraucht ist; in beiden Fällen sagt der Drilldown, welcher der beiden Fälle eingetreten ist, statt das Label stillschweigend fehlen zu lassen.
Bewertungpass, wenn alle erreichbaren Backends dasselbe Zertifikat + dieselbe ausgehandelte Suite teilen (Gewicht 0 – es gibt nichts gutzuschreiben); warn (Gewicht 1) bei Abweichungen; skip, wenn sich kein einziges Backend profilieren ließ. Adressen, zu denen der Scanner keine Route hat (z. B. IPv6 ohne IPv6-Egress), werden als „nicht testbar“ markiert, Adressen, deren Probe auf unserer Seite scheiterte (unsere eigene Zeitüberschreitung, ein abgebrochener Datenstrom), als „nicht ermittelt“ – beides wird nicht gegen den Server gewertet. Eine vom Host abgelehnte oder abgebrochene Verbindung wird als solche gemeldet: Ein TCP-Reset und ein eindeutiges „diesen Namen gibt es nicht“ sind die Antwort der Gegenseite, keine Lücke bei uns.
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 lösen das unterschiedlich: BoringSSL folgt per Default dem Client (die Server-Präferenz-Option ist aus, solange sie niemand setzt), Go/Caddy setzt dagegen immer die eigene Reihenfolge durch und liest die des Clients nur als Indiz – ist deren erste Suite kein AES-GCM, schaltet Go auf eine eigene ChaCha20-zuerst-Liste um, sodass Geräte ohne AES-Hardware trotzdem ChaCha20 bekommen. Go führt das Feld für die Server-Präferenz zwar noch, ignoriert es aber. Geltungsbereich: Der Schalter (nginx ssl_prefer_server_ciphers, OpenSSL SSL_OP_SERVER_PREFERENCE, in OpenSSL 3.6 umbenannt aus SSL_OP_CIPHER_SERVER_PREFERENCE, der alte Name bleibt als Alias) wird hier unter TLS 1.2 gemessen – eine einzelne serverweite Einstellung, die 1.0/1.1/1.2 abdeckt, weshalb dieser Check als „TLS ≤ 1.2“ gekennzeichnet ist. Ob dieselbe Einstellung auch die TLS-1.3-Suite steuert, hängt vom Stack ab: bei OpenSSL ja – ssl3_choose_cipher wendet die Option auch auf TLS 1.3 an. BoringSSL und Go ignorieren sie dort und entscheiden stattdessen nach einer eigenen eingebauten Regel: Go geht seine feste Liste durch und nimmt die erste Suite, die der Client ebenfalls anbietet, während BoringSSL das Angebot des Clients bewertet – ChaCha20 wird nur auf einem Host ohne AES-Hardware bevorzugt – und bei gleichem Ergebnis die Reihenfolge des Clients entscheiden lässt (beide Quellen gelesen 2026-08).
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; wurde die Enumeration der TLS-≤-1.2-Suites nicht abgeschlossen, ist keines von beidem belegbar – das Finding meldet dann info mit Gewicht 0, wenn unser eigener Deckel oder unsere Frist sie beendet hat, und skip mit Gewicht 1 – als nicht gemessen ausgewiesen –, wenn eine Probe von UNS fehlschlug, denn „unbedenklich“ verlangt einen durchgehend starken Satz und „riskant“ eine bekannte schwächere Suite. Bleibt die Präferenz-Probe selbst ohne Antwort, sagt eine Platzhalter-Zeile das, statt dass das Finding aus dem Bericht verschwindet. Das Urteil wird unter TLS 1.2 gemessen und für TLS 1.3 nicht gesondert benotet – ob dieselbe Einstellung auch die TLS-1.3-Suite steuert, hängt vom Stack ab (OpenSSL: ja; BoringSSL und Go ignorieren sie dort und folgen einer eigenen eingebauten Regel, bei der BoringSSL gleich bewertete Suites nach der Reihenfolge des Clients entscheidet — siehe die Beschreibung oben).
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. Keine der drei prüfbaren Engines bietet SHA-224 überhaupt an, und jede stellt SHA-256 und stärker nach vorn: Chrome bietet gar kein SHA-1-Schema an — BoringSSL definiert kein SHA-224-Signaturschema, und Chromiums Verify-Präferenzen führen nur SHA-256+ und ML-DSA-Schemata —, während Firefox rsa_pkcs1_sha1 und ecdsa_sha1 ganz ans Ende seiner Liste stellt, hinter jedes starke Schema; ein Server, der irgendeinen modernen Hash unterstützt, signiert für sie also stark. Safari war hier bisher ausgenommen, weil Apple die verwendete Engine nicht veröffentlicht; abgedeckt ist es jetzt durch Messung statt durch Quelltext: Am 2026-08-29 hat dieser Scanner 56 echte Safari-ClientHellos von drei Geräten auf beiden Apple-Plattformen (iOS 26.6.1, iOS 27 Beta und macOS 26.6.2) aufgenommen, deren signature_algorithms-Liste auf allen dreien byte-identisch ist, mit zehn Signaturschemata — kein einziges SHA-224-Schema, kein ecdsa_sha1, und rsa_pkcs1_sha1 an letzter Stelle hinter jedem starken Schema. Das ist eine Aussage über diese drei Engines und über die genannten Versionen, nicht über jeden Browser, und sie altert: Ein späteres Safari kann seine Liste ändern, ohne dass es jemandem auffällt. 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, wird nicht bemängelt – das wäre ein False Positive. Verbreitet ist das, allgemein aber nicht: Von 20 im August 2026 geprüften bekannten Hosts signierten 11 mit SHA-224, wenn nichts anderes angeboten wurde (darunter CloudFront/Amazon), 9 brachen den Handshake ab. 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 UND jede betroffene Version tatsächlich gemessen wurde; skip mit Gewicht 1 – als nicht gemessen ausgewiesen –, wenn nichts Schwaches gefunden wurde, aber mindestens eine Version nicht prüfbar war, weil eine Probe von UNS fehlschlug, und info mit Gewicht 0, wenn unsere eigene Frist sie beendet hat; die Entwarnung „nur SHA-256+“ wird nur über tatsächlich gemessene Versionen gedruckt; 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 – Clients, für die der Hersteller keine Korrekturen mehr ausliefert (Android ≤7, letztmals in einem Android-Security-Bulletin im Oktober 2019 berücksichtigt; IE 11, Desktop-Anwendung im Juni 2022 eingestellt; OpenSSL 1.0.x, Ende des öffentlichen Supports), sind bewusst ausgeschlossen, weil ihre Kompatibilität keine Aussagekraft für eine aktuelle TLS-Konfiguration hat. Java 8 wird ebenfalls nicht simuliert, aber aus einem anderen Grund und nicht als End-of-Life: Oracle führt es mit Extended Support bis Dezember 2030 und liefert für Privat- und Entwicklungsnutzung über java.com weiterhin freie öffentliche Updates aus (für den kommerziellen Einsatz braucht es seit April 2019 ein Support-Abo) – sein TLS-Profil ist schlicht nicht repräsentativ für die produktiv eingesetzten JDKs. Die Profile sind die dieses Scanners selbst und keine fremde Fähigkeitstabelle. Seit dem 2026-08-29 nennt jedes Profil, woher seine Cipher-Liste stammt, und das Finding richtet seinen Vorbehalt danach aus. Drei sind aus echten ClientHellos auf der Leitung aufgenommen – Chrome 152 unter Linux, Safari unter iOS 26.6.1, iOS 27 Beta und macOS 26.6.2 sowie openssl 3.0.13 s_client –, eine Ablehnung dieser Profile ist also eine Eigenschaft des Servers. Drei sind aus dem veröffentlichten Quelltext des Herstellers abgeleitet: Firefox aus nsNSSComponent.cpp, das erst jede von NSS aktivierte Suite abschaltet und dann genau seine eigene Liste wieder aktiviert; Android 14 aus Conscrypts DEFAULT_X509_CIPHER_SUITES; Java 17 aus CipherSuite.java abzüglich der disabledAlgorithms-Zeile von java.security. Das liegt nah am echten Client, ist aber keine Messung an ihm, und der Unterschied ist keine Pedanterie: Die erste quelltextbasierte Chrome-Liste desselben Tages nannte zwei Suiten, die der ausgelieferte Browser nicht sendet, weil BoringSSL die als deprecated markierten Cipher ausschließt – erst die Aufnahme hat es gezeigt. Eine Auslassung wird benannt statt versteckt: Safari bietet zusätzlich drei 3DES-Suiten an, die der TLS-Build dieses Scanners nicht mehr ausdrücken kann. Ein macOS-Gerät, gemessen am 2026-08-29, machte sein Angebot in zwei Stufen: Seine ersten Verbindungen trugen 13 Suiten, die späteren die vollen 20, die iOS schon mit seinem allerersten Hello sendet – die schmale Menge eine echte Teilmenge der breiten, es fehlen genau die statischen RSA- und die 3DES-Suiten. Die Wiederholung am 2026-08-31 hat das nicht reproduziert: Ein zweites macOS-Gerät mit derselben Safari-Version und ein iPhone boten die breite Liste ab dem allerersten Hello an, an jedem Endpunkt, auch an einem, der das frühere Instrument byte-genau nachbildet. Alle vier Aufnahmen tragen denselben JA3; das schmale Angebot ruht damit auf einem einzigen Gerät und ist keine belegte Eigenschaft von Safari unter macOS. Das Profil behält die breite Liste, und die neuere Messung stützt das: Drei der vier gemessenen Geräte bieten sie bedingungslos an, und nur ein Server, der ausschließlich diese Alt-Suiten anbietet, unterscheidet die beiden überhaupt – dort würde die schmale Liste Safari einen Handshake als gescheitert anlasten, den er zustande bringt. Ein echtes handshake_failure(40) ändert das Angebot überhaupt nicht: 68 Ablehnungen über beide Plattformen ergaben je genau einen JA3, ohne Versions-Fallback und ohne TLS_FALLBACK_SCSV. Offen bleibt allein, ob Safari einen Handshake über AES128-SHA auch zu Ende führt – angeboten hat es die Suite, was nicht dasselbe ist wie benutzt. Die drei Suiten für TLS 1.3 stehen in keiner Liste, weil sie getrennt konfiguriert werden – gemessen sind es genau die, die dieser Build ohnehin per Voreinstellung anbietet. Alle sechs Profile setzen ihren Boden zudem auf TLS 1.2 und ihre Decke auf TLS 1.3, und dieser Boden ist gemessen und nicht angenommen: die aufgenommenen ClientHellos bieten nichts Älteres an, Firefox liefert security.tls.version.min auf TLS 1.2 aus und deaktivierte Versionen abgeschaltet, Java 17 schaltet TLSv1 und TLSv1.1 in java.security ab, und Android 14 tut dasselbe seit seinem Quartals-Release vom Dezember 2023 – nur die am Erscheinungstag eingefrorene Momentaufnahme hatte sie noch an, weshalb der Android-Stempel einen wirklich ausgelieferten Baum nennt.
Bewertungwarn, wenn ein simulierter Referenz-Client (Chrome/Firefox/Safari aktuell, Android 14, Java 17, OpenSSL 3.x) vom Server ABGELEHNT wird; skip mit Gewicht 1 – als nicht gemessen ausgewiesen –, wenn kein Profil abgelehnt wurde, aber eine oder mehrere Proben gar keine Antwort erhielten: Das liegt an unserem Transport, nicht am Server, und der Punkt wird als fehlende Abdeckung gemeldet, statt still aus der Note zu fallen; sonst pass. Gewicht 1.
BehebungDie beiden Ausgänge wiegen nicht gleich, und beide betreffen nur die Aushandlung von Protokoll und Cipher Suite: „verbindet sich“ ist für diese Frage schlüssig – der echte Client bietet mindestens das an, was das Profil anbietet, und handelt erst recht aus –, während „scheitert“ nur so viel wiegt wie das Profil dahinter: schlüssig, wo die Liste aus einem echten Handshake aufgenommen wurde, nah dran aber ungemessen, wo sie aus veröffentlichtem Quelltext abgeleitet ist. Zertifikatsprobleme prüft diese Simulation nicht; dafür stehen die Zertifikats-Findings. Scheitert ein unterstützter Client, Protokolle und Cipher Suites prüfen, vor einer Änderung aber mit dem tatsächlichen Client gegenprü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 jedem 3xx, dessen Location eine https-URL ist (301 und 308 sind beide korrekt; 308 erhält zusätzlich die Methode, RFC 9110 §15.4.9); warn, wenn der erste Hop zwar auf https wechselt, dabei aber nachweislich den Host wechselt – für den eingegebenen Namen lässt sich dann kein HSTS mehr setzen; fail, wenn HTTP ohne Weiterleitung beantwortet wird oder der erste Hop auf ein weiteres http-Ziel im Klartext zeigt; skip, wenn Port 80 die Verbindung ablehnt – ein Host, der auf Port 80 nicht lauscht, hat deshalb keinen Mangel; skip, wenn UNSERE eigene Probe keine Antwort erhielt – das ist keine Aussage über den Server, und die 2 Punkte werden als nicht gemessen ausgewiesen, statt still aus der Note zu fallen. Gefolgt wird nur dem ersten Hop. Gewicht 2.
BehebungAlle HTTP-Anfragen per 301 dauerhaft auf HTTPS umleiten (zusätzlich HSTS setzen).