-
-
Notifications
You must be signed in to change notification settings - Fork 601
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
Allow clients to select a "profile" via ACME API query parameters #7309
Comments
I'm sure it'd currently in active discussing internally, but is there conclusion about how DB should save profiles? |
We haven't yet come to a conclusion on how best to store the profile in the database. The two key considerations are:
The OCSP and CRL systems do not need to know anything about profiles, as far as I'm aware at this time. |
Wonder if it can use https://mariadb.com/kb/en/instant-add-column-for-innodb/ , if mariadb is same version with what docker image grabs it should possible. |
We've discussed this option in the past, and instead opted for other solutions. It is an option again this time, but only one option.
Yes, we've modified the profile in the past. We've also had an incident because of it. So immutable profiles is definitely something we're considering. |
think profile inside order is too early to be immutable, because profile update will need to happen someday (like BR, new or old not allows old one as-is), it only needs to be immutable once it enters finalization and passed to CA. WFE or RA could have hold map of old to new profile hashs and update it at the start of finalization, but now that map needs to be set by human with raw hashes and looks more error prone |
True, good point.
Nah, the CA could just have two maps: human-readable profile name to profile, and content-addressed profile ID to profile. At precertificate issuance time, it would use the first map to look up the correct profile based on the profile name associated with the order. It would then bake the corresponding profile ID into the issuance token. Then at final certificate issuance time, it would use that unique ID to look up the exact same profile for the final certificate. The unique content-addressed hash IDs would be computed inside the CA when it loads its config. |
Adds a new `certProfileName` message to the `CA.IssueCertificateRequest`. This field contains a human-readable "name" set by the [WFE2](#7332), and in turn the RA. At the time of precertificate issuance, the receiving CA will determine if it is capable of fulfilling the `ra.CA.IssuePrecertificate` request for the given `certProfileName`. If the name is found in the CA's map, the CA will return a `capb.IssuePrecertificateResponse` message with a populated `certProfileHash` field back to the RA. When that RA calls `ra.CA.IssueCertificateForPrecertificate`, it will send that same `certProfileHash` message to a CA which must ensure it contains a certificate profile matching the provided hash. If the hash in found in the CA's map a final certificate issuance attempt will proceed. This is done to prevent certificate profile changes in the duration between requests from causing a mismatch between precerticate and final certificate. Part of #7309 Part of #6966
This adds the profile name to the proto messages necessary to propagate it from the WFE to the SA, and from the SA to the CA. This change is safe to land prior to any logic being added, and unblocks profile-handling logic changes to the WFE, RA, SA, and CA. Part of #7309
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 design we have landed on is
Subtasks:
The text was updated successfully, but these errors were encountered: