Wikipedia may not yet provide current information:
https://en.wikipedia.org/wiki/Security.txt

Examples:
https://www.ncsc.nl/.well-known/security.txt
https://www.sidn.nl/.well-known/security.txt
https://internet.nl/.well-known/security.txt

How my hosted sites use .htaccess:
Redirect 302 /.well-known/security.txt https://janwillemstegink.nl/.well-known/security.txt

If legacy functionality is a requirement:
Redirect 302 /security.txt https://janwillemstegink.nl/.well-known/security.txt

For cloud operators:

• A CMS can generate security.txt daily.
• A CMS could delete security.txt if still directly under public_html.
• In case of required legacy retrieval, redirection works.

Tools:

https://securitytxt.org
https://www.uriports.com/tools/securitytxt-validator

Code for GPG encryption, working for me:

In /home/[username]/:

$ gpg --list-secret-keys
copy value in:
% gpg --delete-secret-key 7D2BAF1CF37B13E2069D6956105BD0E739499BDB

$ gpg --list-keys
copy value in:
$ gpg --delete-key DA00BA63132526028F91B736943E4C27C0572269

$ gpg --full-generate-key
Choose option 1 with RSA if e.g. AlmaLinux 8 does not support the more efficient ed25519 encryption (option 9).
Real Name: eg. janwillemstegink.nl
Comment: eg. 2025
if RSA: 4096
A paraphrase to choose
Life Time can be chosen as zero

$ gpg --output public.asc --armor --export techdesk@hostfusion.nl
Optional:
$ gpg --output private.asc --armor --export-secret-key techdesk@hostfusion.nl

$ cp public.asc (to webserver level)
----------------------------------------

In /.well-known/:

Content without encryption in security-content.txt:
Eg. Encryption: https://janwillemstegink.nl/public.asc

$ gpg --clearsign -o security.txt security-content.txt

Test on https://www.uriports.com/tools/securitytxt-validator

You can see a finishing blank line after the key with View source code and the url in Chrome.

ChatGPT about a finishing CRLF:
There is no requirement in either RFC 4880 or RFC 9116 that a blank line must follow the closing line in the context of security.txt.
Some linters, validators, or web servers may behave differently when parsing files with/without final newlines.
If you're distributing security.txt via HTTP, it's good practice to:
- Stick with CRLF line endings throughout,
- And optionally end with a newline, to stay compatible with traditional Unix text tools.

$ rm security-content.txt

Note: After a change such as commenting out a line, fresh encryption is necessary.