I'm experiencing an issue when using the profile: 'classic' setting in new order requests with Let's Encrypt's ACME API. According to the FAQ, Let's Encrypt reuses valid and not expired authorizations across orders for the same account key.
Steps to Reproduce:
Create an order for domain.com and www.domain.com using profile: 'classic'.
Fulfill the challenge only for domain.com successfully.
Attempt to create a new order for domain.com using profile: 'classic'.
Observe that a new authorization challenge is created, even though a valid authorization exists.
Expected Behavior:
The existing valid authorization for domain.com should be reused in the new order, and the order should be marked as "ready" without requiring a new challenge.
Actual Behavior:
A new authorization challenge is created, and the order is not marked as "ready" until the new challenge is completed.
Additional Information:
When profile: 'classic' is not used in the order, everything works as expected: valid authorizations are reused, and the order is marked as "ready" without needing a new challenge.
Environment:
ACME Server: Let's Encrypt (Staging and Production)
Profile:classic
Question:
Is the authorization cache intended to work with the profile: 'classic' setting? If so, could there be an issue with the implementation or a misconfiguration on my part?
I wasn’t sure if this behavior is a bug or an intended feature. The profile integration documentation doesn’t clearly specify what changes and what remains the same. Based on my observations, it seems that the "classic" behavior should be the same as when no profile is used.
However, since I couldn’t find a straightforward way to list my account’s orders, identifying this issue was a bit challenging. If there’s an easy method to view all orders, so I can check which authorizations were used, I’d really appreciate it. That would help us integrate this into our regression tests and allow us to report any future issues more efficiently.
Thank you for addressing this so promptly. Please let me know what I should follow or check in order to know when the fix has been applied to your staging and production environments. This issue is currently blocking our profile integration in production, and we need to be absolutely sure we’re using the correct profiles. According to the documentation: *“For the vast majority of Let’s Encrypt subscribers, you should never have to worry about this: we automatically select the best profile for you,” - which, from my perspective, is a bit concerning.
Unfortunately there isn't. LetsEncrypt decided against integrating the ACME endpoint for listing orders as a launch blocker, and it has remained a very low priority item for years. Client authors are encouraged to log/track all orders in a way that Subscribers can easily audit them; unfortunately, most don't do that either.
For what it's worth, I'd suggest that it shouldn't. Authorization reuse should only ever be a nice-to-have, not something that your system requires to function properly. Because authorization reuse is not a standardized part of the ACME protocol itself, our authorization reuse rules may change at any time. And we may purge all currently-valid authorizations at any time due to an incident or similar circumstance.
This is the way it has always worked: when a client has requested issuance, we've done our best to issue a certificate that complies with all relevant requirements, maximizes compatibility with various (old) browser trust stores, and minimizes certificate size. Our profile has changed many times over the last decade, and some of those changes have unfortunately had to be disruptive for out-of-date clients.
The point of that sentence is that the introduction of profiles doesn't meaningfully change that contract. If you don't request a specific profile, we'll do what we've always done and give you a cert that we think best balances the compatibility and size concerns above. And even if you do request a specific profile, the contents of that profile will change over time as the relevant requirements/regulations change. We're giving you more control, but not perfect control.
Correct -- it would be very surprising if an authz created for a shortlived order were then able to be reused to issue a long-lived certificate, resulting in a certificate which vastly outlives the cert for which the authz was originally created. We're trying to divine and then respect client intent in the least surprising way possible.
While LE doesn't support pre-authorization, if other CA want to use profile and preauth, only choice for them is preauth is valid for all profiles as there is no data about what profiles it should valid for in current message. Guess ietf profile draft need an update for mechanisms about selecting profile in preauth request.
The draft should probably also have some MUST NOT and SHOULD NOT text about ensuring against "an authz created for a shortlived order were then able to be reused to issue a long-lived certificate".
That's a good point! I'll have to think about how profiles and pre-authorization requests should interact. It's a bit messy.
Here I definitely disagree. For starters, the profiles document says nothing about what aspects of a certificate can be controlled by a profile. That's wholly up to the CA. So speaking about one particular certificate attribute and not addressing others (should an authz for a DV-only profile be able to be reused for an EV certificate?) would be very out of place. Also, other CAs (or other PKIs even) may very reasonably make the decision that they think reusing authzs across profiles is fine. We're making a judgement call here, not making a set-in-stone standard.
I think that's the blurry line about being an industry-leader and trend-setter: the de facto "standards" that result. First practice becomes best practice until something better comes along. Not criticizing here. On the contrary, if anything I think this emphasizes the importance of thoughtful policy discussion and brings due respect to such efforts. Questions test the rigors of the structure and the industry is better for it. I give respect to all sides of good discussion.
The above was intended to read "MUST NOT or SHOULD NOT". Your judgement call makes perfect sense, and is something that other CAs will potentially overlook. IMHO, guiding other CAs via the RFC makes more sense than this waiting for this to become an issue. A CA should ensure that authz for short profiles are not reused for substantially longer profiles - or at least understand the security implications. That is an incredible bit of insight, concern and/or learnings from real-world applications that you have developed.
RFCs often have a "special considerations" section to outline edge cases and unique situations to address things like "speaking about one particular certificate attribute and not addressing others".