Check your security.txt, signature and keys included
Enter your domain. The check fetches the file, verifies structure, expiry date, links, keys and the OpenPGP signature, and tells you how to fix each finding.
- Free, no sign-up
- Signature verified cryptographically
- RFC 9116 or TR-03183-3, your choice
What the check covers
The rules come from RFC 9116 and sections 4.2 and 4.3.2 of BSI TR-03183-3. Every finding cites the clause it is based on.
Retrieval
Is the file at /.well-known/security.txt, reachable over HTTPS with a valid certificate? Where do redirects lead? Does the server send text/plain; charset=utf-8 or an error page dressed as HTML? Does a firewall block automated requests, which the TR rules out in section 4.2.11?
Structure and content
Every line is a field or a comment, values in ASCII only. Contact and Expires are present, Expires exactly once, in RFC 3339 format and at most one year ahead. Canonical names the actual location. Linked pages respond, mail domains have an MX record. Typical mistakes such as Acknowledgements instead of Acknowledgments are caught, and the newer fields CSAF and Bug-Bounty are known.
Signature and keys
If the file is signed, the check verifies the OpenPGP signature cryptographically: with the keys from the Encryption fields, from the reporting page or, if none fits, from keys.openpgp.org. Plus key length, hash algorithm, expiry and the five-year limit of the TR.
BSI TR-03183-3
With the stricter standard: contacts in the order PSIRT, CSIRT, reporting page, recognisable role mailboxes, one key per mailbox as .asc, English in Preferred-Languages, Policy, a mandatory signature and the recommended comments.
What no check can see
Whether anyone reads the mailbox, whether the policy holds up and whether reporters get a timely answer. Only a real case or a test run shows that: send a message to the address yourself.
No file yet? The generator writes one in a few minutes. All fields and the most common mistakes are explained in the guide.