Directory served directly with 200

What this check verifies

The protocol draft (draft-ietf-webbotauth-httpsig-protocol-00, section 5.5) sets two rules for every resource a verifier fetches to find your keys:

1. It must be served with HTTP status 200 (OK). A verifier treats every other status as a discovery failure.
2. A verifier must not follow HTTP redirects automatically.

The checker follows redirects itself, so it can still grade the directory at the end of the chain. This check then reports what a verifier that follows the draft would see:

• The directory was reached through a redirect: warning. The message names the URL the checker requested and the URL the chain ended at. When the chain ends at the well-known path on another origin, it names that origin as the one your Signature-Agent header should name; otherwise it advises serving the key set at the well-known path without a redirect, or advertising the final URL as a type=jwks_uri member.
• The directory answered directly, but with a 2xx status other than 200: warning.
• The directory answered directly with 200: pass.

The check is advisory. It lowers the score but never caps the grade and never changes the verdict. A response outside the 2xx range is a different case: Directory endpoint reachable reports it, and the verdict is NOT FOUND.

Why it matters

A verifier turns the origin in your Signature-Agent header into one URL, https://<origin>/.well-known/http-message-signatures-directory, and fetches it. If that URL redirects, for example from example.com to www.example.com, a verifier that follows the draft stops at the redirect and gets no keys. A browser or this checker still finds the directory, so the problem is easy to miss.

Without keys the verifier cannot attribute the request to your URL (section 6.10), and your signed requests stay unverified, however correct the directory is.

How to fix it

1. Serve the directory directly, with status 200, at the origin your Signature-Agent header names.
2. If your site redirects the apex to www (or the other way round), either exempt the well-known path from that redirect, or change the Signature-Agent value to the origin that serves the directory, for example https://www.example.com.
3. Return the key set with 200, not another 2xx code.

Request the well-known URL with a client that does not follow redirects and confirm the status line reads 200.

References

• The Web Bot Auth protocol draft (draft-ietf-webbotauth-httpsig-protocol-00), section 5.5, requires status 200 and forbids following redirects; section 6.10 describes what a failed discovery means for the verifier.
• RFC 8615 defines well-known URIs.
• How grading works explains how advisory warnings affect the score.