security.txt Check nach RFC 9116 und BSI TR-03183-3
Geben Sie Ihre Domain ein. Der Check ruft Ihre security.txt ab, prüft Aufbau, Ablaufdatum, Verweise, Schlüssel und Signatur und sagt zu jedem Befund, wie Sie ihn beheben.
Kostenlos, ohne Anmeldung. Unser Server ruft die öffentliche Datei und die darin verlinkten Adressen ab. Wir speichern die geprüfte Domain und die Art der Befunde, nicht den Inhalt der Datei (Datenschutz). Grundlage: RFC 9116, BSI TR-03183-3 Version 1.0.0. Keine Rechtsberatung.
Überwachung: Wir behalten Ihre security.txt im Blick
Eine security.txt veraltet still. Das Ablaufdatum läuft ab, ein Schlüssel verfällt, nach einem Relaunch fehlt die Datei. Prüfdienste werten sie dann als ungültig, und wer eine Schwachstelle melden will, findet keinen Kontakt.
- Regelmäßige Prüfung mit denselben Regeln wie dieser Check, nach RFC 9116 und BSI TR-03183-3.
- Erinnerung rechtzeitig vor dem Ablaufdatum der Datei und vor dem Ablauf Ihrer Schlüssel.
- Nachricht, sobald die Datei fehlt, die Signatur nicht mehr passt oder ein Verweis ins Leere führt.
- Prüfbericht als Nachweis für die vierteljährliche Prüfung, die die TR verlangt (Abschnitt 4.2.9 c).
5 Euro im Monat je Domain, jährlich abgerechnet (60 Euro im Jahr). Preise netto zuzüglich Umsatzsteuer.
Was der Check prüft
Die Regeln stammen aus RFC 9116 und aus Abschnitt 4.2 und 4.3.2 der BSI TR-03183-3. Jeder Befund nennt die Stelle, auf die er sich stützt.
Abruf
Liegt die Datei unter /.well-known/security.txt, erreichbar über HTTPS mit gültigem Zertifikat? Wohin führen Weiterleitungen? Liefert der Server text/plain; charset=utf-8 oder eine Fehlerseite im HTML-Gewand? Sperrt eine Firewall automatische Abrufe aus, wie es die TR in Abschnitt 4.2.11 ausschließt?
Aufbau und Inhalt
Jede Zeile ist ein Feld oder ein Kommentar, Werte nur in ASCII. Contact und Expires sind vorhanden, Expires genau einmal, im Format nach RFC 3339 und höchstens ein Jahr voraus. Canonical nennt den tatsächlichen Fundort. Verlinkte Seiten antworten, Maildomains haben einen MX-Eintrag. Typische Fehler wie Acknowledgements statt Acknowledgments fallen auf.
Signatur und Schlüssel
Ist die Datei signiert, prüft der Check die OpenPGP-Signatur kryptografisch: mit den Schlüsseln aus den Encryption-Feldern oder, falls dort keiner passt, mit keys.openpgp.org. Dazu Schlüssellänge, Hashverfahren, Ablauf und die Fünf-Jahres-Grenze der TR.
BSI TR-03183-3
Im strengeren Maßstab: Kontakte in der Reihenfolge PSIRT, CSIRT, Meldeseite, erkennbare Funktionspostfächer, je Postfach ein Schlüssel als .asc, Englisch in Preferred-Languages, Policy, Signaturpflicht und die empfohlenen Kommentare.
Was kein Check sieht
Ob jemand das Postfach liest, ob die Richtlinie trägt und ob bei einer aktiv ausgenutzten Schwachstelle die Meldung nach Artikel 14 binnen 24 Stunden rausgeht. Das prüft nur der Ernstfall oder ein Probelauf.
Noch keine Datei? Der security.txt Generator schreibt sie in wenigen Minuten. Alle Felder und die häufigsten Fehler erklärt die Anleitung zur security.txt.
Die Datei stimmt. Wer liest das Postfach?
CRA Response Center nimmt Meldungen an Ihrer Adresse an, prüft jede auf Hinweise für die Meldepflicht und weckt Ihre Rufkette, auch nachts und am Wochenende. Sie entscheiden, wir halten den Ablauf und den Nachweis.