crl-updater: query by explicit shard too #7973
Merged
+410
−65
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add querying by explicit shard (SA.GetRevokedCertsByShard) in addition to querying by temporal shard (SA.GetRevokedCerts).
Merge results from both kinds of shard. De-duplicate by serial within a shard, because the same certificate could wind up in a temporal shard that matches its explicit shard.
When de-duplicating, validate that revocation reasons are the same or (very unlikely) represent a re-revocation based on demonstrating key compromise. This can happen because the two different SA queries occur at slightly different times.
Add unit testing that CRL entries make it through the whole pipeline from SA, to CA, to uploader.
Rename some types in the unittest to be more accessible.
Tweak a comment in SA.UpdateRevokedCertificate to make it clear that status and reason are critical for re-revocation.
Note: This GetRevokedCertsByShard code path will always return zero certificates right now, because nothing is writing to the
revokedCertificates
table. Writing to that table is gated on certificates having CRL URLs in them, which is not yet implemented (and will be config-gated).Part of #7094