Die Warnung statt der Startseite
Ein Interessent gibt Ihre Adresse ein und sieht statt der Startseite eine ganzseitige Warnung: Die Verbindung sei nicht sicher. Er schließt das Fenster. Bei Ihnen fällt das niemandem auf, denn eine Anfrage, die nie abgeschickt wurde, hinterlässt keine Spur.
Dafür braucht es keinen Angriff. Es genügt ein Zertifikat, das vorgestern abgelaufen ist.
Vier Dinge, die jeder sehen kann
Ihre Website liefert mit jeder Seite Angaben aus, die jeder Besucher und jedes Prüfwerkzeug lesen kann. Vier davon entscheiden, ob Besucher Ihre Seite ohne Warnung erreichen und wie gut sie dabei geschützt sind:
| Was | Woran man es sieht | Stimmt es nicht, dann |
|---|---|---|
| Zertifikat | Laufzeit und Aussteller, ein Klick auf das Schloss im Browser | zeigt der Browser eine Warnung statt Ihrer Seite |
| Verschlüsselte Adresse | Ihre Seite antwortet unter https://, mit und ohne www | erhalten Besucher eine Fehlermeldung |
| Sicherheitskopfzeilen | fünf Angaben, die der Webserver mit jeder Seite schickt | lässt der Browser mehr zu als nötig |
| Sichtbare Version | das System Ihrer Website nennt sich im Quelltext mit Versionsnummer | findet, wer nach verwundbaren Versionen sucht, Ihre Seite ohne Aufwand |
Das Zertifikat hat ein Ablaufdatum, und die Abstände werden kürzer
Das TLS-Zertifikat weist Ihre Website gegenüber dem Browser aus und verschlüsselt die Verbindung. Es gilt nur für einen festen Zeitraum, und dieser Zeitraum schrumpft. Zertifizierungsstellen und Browserhersteller haben im CA/Browser Forum beschlossen:
Bei 47 Tagen braucht eine Website mindestens acht Zertifikate im Jahr. Nach Kalender und von Hand geht das nicht mehr zuverlässig. Viele Hoster und Webserver können die Erneuerung automatisch erledigen, etwa über das Verfahren ACME, das auch Let's Encrypt nutzt.
Die entscheidende Frage ist deshalb nicht, wann das Zertifikat abläuft, sondern ob seine Erneuerung ohne einen Menschen funktioniert.
| Ausgestellt ab | höchstens gültig |
|---|---|
| 15.03.2026 | 200 Tage |
| 15.03.2027 | 100 Tage |
| 15.03.2029 | 47 Tage |
Die Adresse ohne www
Häufig ist nur eine Variante der Adresse richtig eingerichtet. Mit www erscheint die verschlüsselte Seite, ohne www eine Fehlermeldung, oder die unverschlüsselte Adresse leitet nicht weiter. Ausgerechnet die kurze Form steht dann auf Visitenkarten und in Signaturen.
Prüfen lässt sich das selbst: Rufen Sie alle vier Varianten auf, http und https, jeweils mit und ohne www. Jede sollte ohne Warnung auf dieselbe verschlüsselte Seite führen.
Sicherheitskopfzeilen: fünf Zeilen Konfiguration
Mit jeder Seite schickt der Webserver Kopfzeilen, die dem Browser sagen, was er zulassen darf. Fünf davon sind verbreitet:
Einzeln ist eine fehlende Kopfzeile selten ein Einfallstor. Zusammen erschweren sie bekannte Angriffe auf Ihre Besucher, etwa das unsichtbare Einbetten Ihrer Seite in eine fremde Seite, die Besucher zu ungewollten Klicks verleitet. Die ersten vier sind reine Konfiguration am Webserver, ohne Eingriff in die Website selbst.
Die Content-Security-Policy braucht Sorgfalt. Zu streng eingestellt, legt sie Kontaktformular, Karte oder Statistik der eigenen Seite lahm. Deshalb setzt man sie zuerst im Berichtsmodus (Content-Security-Policy-Report-Only) und schaltet sie erst scharf, wenn keine Meldung mehr kommt.
| Kopfzeile | Sagt dem Browser |
|---|---|
| Strict-Transport-Security | diese Seite nur verschlüsselt aufrufen, auch wenn jemand http eintippt |
| X-Content-Type-Options | Dateien nur als das behandeln, als was der Server sie ausweist |
| X-Frame-Options | die Seite nicht in fremde Seiten einbetten, heute oft über frame-ancestors in der Content-Security-Policy |
| Referrer-Policy | wie viel von der aufgerufenen Adresse an andere Seiten weitergeht |
| Content-Security-Policy | von welchen Quellen Skripte, Schriften und Bilder geladen werden dürfen |
Die sichtbare Version
Viele Websites nennen im Quelltext das System, mit dem sie gebaut sind, samt Versionsnummer, meist in einer Zeile mit dem Namen generator. Für sich ist das keine Lücke. Wer aber gezielt nach Seiten mit einer bestimmten verwundbaren Version sucht, findet Ihre damit ohne Aufwand.
Entscheidend ist deshalb der Stand dahinter: ob System, Erweiterungen und Designvorlagen aktuell sind, und wer die Aktualisierungen einspielt. Angriffe auf bekannte Lücken in veralteten Versionen laufen automatisiert, sie fragen nicht nach Größe oder Branche. Ist das geregelt, blendet man die Versionsangabe aus. Ausblenden allein ändert nichts.
Wie Sie es selbst prüfen
Zertifikat: Klicken Sie im Browser auf das Schloss neben der Adresse, dann auf die Angaben zum Zertifikat. Dort steht, bis wann es gilt.
Adresse: Rufen Sie die vier Varianten aus dem Abschnitt oben auf.
Kopfzeilen: Unter Windows zeigt die Eingabeaufforderung alle Kopfzeilen Ihrer Startseite:
curl -sI https://ihre-domain.de
Taucht eine der fünf nicht auf, fehlt sie.
Version: Öffnen Sie im Browser mit Strg+U den Quelltext der Startseite und suchen Sie nach generator.
Was das im Betrieb bedeutet
Die Website ist für viele Interessenten der erste Kontakt, lange vor dem ersten Anruf. Eine Warnung an dieser Stelle kostet keine Daten, aber Anfragen, und zwar unbemerkt: Eine Anfrage, die nie abgeschickt wird, taucht in keiner Statistik auf.
Liegt die Website bei einer Agentur oder einem Hoster, lohnt eine Frage: Wer erneuert das Zertifikat, und wer spielt Aktualisierungen ein? Eine Antwort mit Namen ist gut. „Das läuft automatisch“ ist eine Antwort, die man einmal nachprüfen sollte.
Der Aufwand
| Schritt | Aufwand |
|---|---|
| Automatische Erneuerung des Zertifikats einrichten | beim Hoster oft eine Einstellung, am eigenen Server eine einmalige Einrichtung |
| Alle Adressvarianten auf die verschlüsselte Seite leiten | eine Weiterleitungsregel am Webserver |
| Vier einfache Kopfzeilen setzen | Konfiguration am Webserver, ohne Eingriff in die Website |
| Content-Security-Policy | erst Berichtsmodus, nach einigen Wochen scharf schalten |
| Aktualisierungen regeln, Versionsangabe ausblenden | eine Zuständigkeit festlegen, dann eine Einstellung |
Was diese Prüfung nicht leistet
Alle vier Punkte sind von außen sichtbar, und genau deshalb sind sie nur die Oberfläche. Sie sagen nichts darüber:
Eine Prüfung der Kopfzeilen ist kein Penetrationstest und ersetzt keinen.
- ob die Website selbst Lücken hat, etwa im Kontaktformular
- wie gut die Zugänge zur Verwaltung der Website geschützt sind
- ob es eine aktuelle Sicherung der Website gibt
Häufige Fragen
Unsere Website hat nur ein Impressum und keine Formulare. Betrifft uns das? Beim Zertifikat und bei der verschlüsselten Adresse ja, denn die Warnung zeigt der Browser unabhängig vom Inhalt. Bei den Kopfzeilen ist der Nutzen kleiner, der Aufwand aber auch.
Unser Hoster kümmert sich doch darum. Das kann gut sein. Fragen Sie nach, was genau enthalten ist: die Erneuerung des Zertifikats, die Kopfzeilen, die Aktualisierung von System und Erweiterungen. Das sind drei verschiedene Leistungen.
Müssen wir wegen der kürzeren Laufzeiten etwas tun? Wenn die Erneuerung schon automatisch läuft, nein. Wer das Zertifikat bisher einmal im Jahr von Hand einspielt, kann das seit März 2026 nicht mehr: Neue Zertifikate gelten höchstens 200 Tage, ab März 2027 höchstens 100.
Wenn Sie wissen möchten, wie Ihre IT dasteht
Die Website ist nur der sichtbare Teil. Wenn Sie wissen wollen, wie Ihre IT insgesamt dasteht: Unsere Infrastrukturanalyse ist kostenlos und unverbindlich. Wir prüfen Ihre gesamte IT-Infrastruktur und dokumentieren diese. Schreiben Sie uns über die Kontaktseite auf virmas.de.
VIRMAS Systemtechnik GmbH ist ein IT-Systemhaus für Geschäftskunden in Neuenhagen bei Berlin; wir betreuen Unternehmen in Berlin und Brandenburg, mit einem festen Ansprechpartner statt einer anonymen Hotline.
Quellen
CA/Browser Forum: Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods, angenommen im April 2025 · CA/Browser Forum: Baseline Requirements, Abschnitt 6.3.2 · ACME: RFC 8555, Automatic Certificate Management Environment · HSTS: RFC 6797, HTTP Strict Transport Security · X-Frame-Options: RFC 7034, HTTP Header Field X-Frame-Options · Content-Security-Policy: W3C, Content Security Policy Level 3 · Referrer-Policy: W3C, Referrer Policy · X-Content-Type-Options: WHATWG, Fetch Standard · MDN Web Docs: HTTP-Header
- CA/Browser Forum: Ballot SC081v3, Introduce Schedule of Reducing Validity and Data Reuse Periods, angenommen im April 2025
- CA/Browser Forum: Baseline Requirements, Abschnitt 6.3.2
- ACME: RFC 8555, Automatic Certificate Management Environment
- HSTS: RFC 6797, HTTP Strict Transport Security
- X-Frame-Options: RFC 7034, HTTP Header Field X-Frame-Options
- Content-Security-Policy: W3C, Content Security Policy Level 3
- Referrer-Policy: W3C, Referrer Policy
- X-Content-Type-Options: WHATWG, Fetch Standard
- MDN Web Docs: HTTP-Header