-
-
Notifications
You must be signed in to change notification settings - Fork 607
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RA: compute CRL shard upon revocation #7133
base: main
Are you sure you want to change the base?
Conversation
@aarongable, this PR appears to contain configuration changes. Please ensure that a corresponding deployment ticket has been filed with the new configuration values. |
171c3d1
to
c92ba2b
Compare
a360f72
to
a21e729
Compare
a21e729
to
69f755d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
crlDPBase, crlNumShards, and crlShardWidth
...
Therefore these values must exactly match the crl-updater's numShards and shardWidth config values.
Seems like making them match might be slightly easier if RA grouped these config fields into a struct "crls"
with numShards
and shardWidth
as fields of that struct (i.e. use the same field names as crl-updater).
@@ -2148,9 +2212,15 @@ func (ra *RegistrationAuthorityImpl) RevokeCertByKey(ctx context.Context, req *r | |||
} | |||
|
|||
issuerID := issuance.GetIssuerNameID(cert) | |||
crlShard, err := ra.crlShardForCert(cert) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The certificate here hasn't been validated as signed by our issuer and we haven't checked that we actually have this issuer. While the WFE has checked those properties, given that the importance of getting the crlShard right, maybe we should do it here too? Or perhaps just look up the cert in our database and verify the two are identical?
I've uploaded a commit which addresses most of jsha's comments. However, I'm putting this PR back into Draft mode because we've decided that this PR will end up more elegant if we first address #7159, and then do the shard index extraction in the CA instead of in the RA. |
Add three new config values to the RA: crlDPBase, crlNumShards, and crlShardWidth. When a revocation request comes in, use these values to compute the CRL Shard that the revoked cert falls into, and include that shard number in the RevokeCertificate request to the SA. This will cause the SA to create a row in the revokedCertificates table, thanks to #7095.
The first new config value is used to extract the appropriate shard number from a CRL Distribution Point URL already embedded in the to-be-revoked certificate. Therefore, this value must exactly match the crlDPBase config item in the CA, which controls the CRL URLs it generates.
However, that method only works once CRLDP URLs are baked into certs, which isn't the case yet. So the second and third new config values are used to directly compute the appropriate shard based on the certificate's notAfter date, in the same way that crl-updater computes that mapping today. Therefore these values must exactly match the crl-updater's numShards and shardWidth config values.
All of the code described above only becomes active once all three new config fields are specified in the RA. This allows this change to be deployed safely, and turned on later by setting those config values.
Also update the RA's audit log for administratively-revoked certificates to include the correct revocation method name.
Part of #7094