Design and implement a system for automatically rejecting requests from doomed clients #7406
Closed
17 tasks done
Assignees
Comments
beautifulentropy
changed the title
beautifulentropy
added a commit
that referenced
this issue
Jun 20, 2024
beautifulentropy
pushed a commit
that referenced
this issue
Jul 10, 2024
…7500) Adds a new boulder component named `sfe` aka the Self-service FrontEnd which is dedicated to non-ACME related Subscriber functions. This change implements one such function which is a web interface and handlers for account unpausing. When paused, an ACME client receives a log line URL with a JWT parameter from the WFE. For the observant Subscriber, manually clicking the link opens their web browser and displays a page with a pre-filled HTML form. Upon clicking the form button, the SFE sends an HTTP POST back to itself and either validates the JWT and issues an RA gRPC request to unpause the account, or returns an HTML error page. The SFE and WFE should share a 32 byte seed value e.g. the output of `openssl rand -hex 16` which will be used as a go-jose symmetric signer using the HS256 algorithm. The SFE will check various [RFC 7519](https://datatracker.ietf.org/doc/html/rfc7519) claims on the JWT such as the `iss`, `aud`, `nbf`, `exp`, `iat`, and a custom `apiVersion` claim. The SFE should not yet be relied upon or deployed to staging/production environments. It is very much a work in progress, but this change is big enough as-is. Related to #7406 Part of #7499
This was referenced Jul 10, 2024
beautifulentropy
added a commit
that referenced
this issue
Jul 25, 2024
This was referenced Jul 30, 2024
beautifulentropy
added a commit
that referenced
this issue
Jul 31, 2024
Currently, the SFE displays "An error occurred while unpausing your account" in scenarios where it's not correct or helpful. - Return a helpful message when a Subscriber attempts to access the unpause form but fails to copy the entire link - Return a helpful message when a Subscriber attempts to unpause using an expired JWT - Some small cleanups that make the code a little more mistake-proof. Part of #7406
beautifulentropy
added a commit
that referenced
this issue
Jul 31, 2024
Call `RA.UnpauseAccount` for valid unpause form submissions. Determine and display the appropriate outcome to the Subscriber based on the count returned by `RA.UnpauseAccount`: - If the count is zero, display the "Account already unpaused" message. - If the count equals the max number of identifiers allowed in a single request, display a page explaining the need to visit the unpause URL again. - Otherwise, display the "Successfully unpaused all N identifiers" message. Apply per-request timeout from the SFE configuration. Part of #7406
aarongable
pushed a commit
that referenced
this issue
Aug 22, 2024
Implements tooling in `admin` that allows an operator to administratively pause account/identifier pairs and unpause whole accounts. This functionality mirrors the self-service capabilities of the SFE, so that we can administratively intervene in the pausing and unpausing process. The new `pause-identifier` subcommand accepts a single form of input, specified by the `-batch-file` flag. This expects a CSV where each row is an accountID, identifierType, identifierValue triple. The new `unpause-account` subcommand accepts either a single account ID with the `-account` flag, or a text file containing a list of account IDs with the `-batch-file` flag. Relates to #7406 Fixes #7618
|
This is fully announced and deploying this week. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This bug is an umbrella/tracking bug, acting as a one-stop-shop to see progress on the multiple sub-tasks necessary to achieve this 2024 OKR.
The text was updated successfully, but these errors were encountered: