On Thu, Mar 12, 2026 at 01:39:12PM -0700, Aaron Gable wrote: > What follow are all of the reasonable approaches that have occurred to me, > presented in order from least to most desirable in my personal opinion: > > 1) Add a new field to the Order object, so that a finalized MTC order can > have both a "certificate" URL and a "landmarkCertificate" URL or something > like that. This is simple, and makes it very clear to the client that only > one of the two expected certificates has been issued so far.
I think this is the best option. Much cleaner than replacing certificates or messing with alternates (which landmark certificates are not). The client processing is also simple: Save the information along the obtained standalone certificate, and then download and install the landmark certificate (as a separate job!) later. > But it may > cause breakage in clients that don't like unexpected fields when parsing > JSON objects, and it feels overly-specific: why should the entire ACME > protocol have to know about landmark certificates, even when deployed in > private PKIs that aren't using MTC? Presumably the field would only be present in orders for MTC certificates, so that clients do not break and non-MTC PKIs do not have to care about it. Any client that would be broken by the new field is broken by MTC itself anyway. Maybe even include estimate of when the landmark certificate will be available to the valid order object, so the clients do not need to try to download it to get that information. -Ilari _______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
