Making and signing security.txt
When someone finds a problem in your system, the question "to whom does he report it?" is not a policy question but a path question: does a file stand at `/.well-known/security.txt` that answers him? RFC 8615 describes that file, the standard location, the legacy path `/security.txt`, and the fields that belong there: contact, expires, and optionally policy, canonical and a PGP key reference.
The security.txt tool checks both paths and reads what stands — and on the other side of the page you build one yourself: fill in fields, file ready for placement, and if desired sign it. An unsigned file is a text belonging to your domain; a clearsigned file is additionally proof that the text is yours.
This article covers making, placing and signing — and how to check that your own signature holds before you let another rely on it.
Both paths, one content
RFC 8615 knows the standard location under `.well-known/` and names `/security.txt` as a legacy path you may serve, but not as a replacement. Serving at both paths, with the same content, is the practice that serves both the standard-following crawler and the older finder. References at two locations with different content — that is what the tool sets apart first.
Expires is no detail
The field `expires` says how long the content may still count as current. A security.txt with a lapsed expires is worse than no file: it signals that someone once took it seriously and then left it lying. The tool reports a lapsed expires as a measured shortfall — a date here is no decoration.
Signing: proving it is yours
A clearsigned security.txt (OpenPGP signature around the text) makes the content proof-of-ownership: someone reporting a problem sees that the document really belongs to the domain. Run your own key block through the PGP reader before you sign: fingerprint, algorithm and subkeys — checking what you are about to place, before it is public.
Before the incident
A reporting point only has value if it stands before there is something to report. Place the file, place the expires, and repeat the check on both paths when you change your certificate or nameserver (securing a website names those moments; the mail-trust layer is the subject where security.txt often belongs — security incidents and mail abuse live in the same houses).