CRLs: Add crl storage proxy #6162
Assignees
Milestone
Comments
aarongable
added a commit
that referenced
this issue
Aug 8, 2022
Create a new crl-storer service, which receives CRL shards via gRPC and uploads them to an S3 bucket. It ignores AWS SDK configuration in the usual places, in favor of configuration from our standard JSON service config files. It ensures that the CRLs it receives parse and are signed by the appropriate issuer before uploading them. Integrate crl-updater with the new service. It streams bytes to the crl-storer as it receives them from the CA, without performing any checking at the same time. This new functionality is disabled if the crl-updater does not have a config stanza instructing it how to connect to the crl-storer. Finally, add a new test component, the s3-test-srv. This acts similarly to the existing mail-test-srv: it receives requests, stores information about them, and exposes that information for later querying by the integration test. The integration test uses this to ensure that a newly-revoked certificate does show up in the next generation of CRLs produced. Fixes #6162
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The crl updater which manages the whole crl generation process needs to talk both to the CA (for signing) and to the public internet (for uploading). That's unfortunate. Instead, create a crl storage "proxy" (filling a role similar to the ocsp-responder) which can live in a less-privileged network segment, and which handles all talking to the public internet.
The text was updated successfully, but these errors were encountered: