I sometimes (non-deterministically) receive an error “Order’s status (“valid”) is not acceptable for finalization” when I try to call acme-client’s poll_and_finalize on an order. I thought the order status should be “ready” before “valid”, and in that state I can finalize it. However, I am unsure what is happening to cause it to be valid. At any rate, is it possible to “refresh” my order, so that I can see the order in Python and be able to access the certificate URI?
Some other information that may help: There may be multiple certificate requests created for the same set of domains (These tests tend to happen as part of an integration test suite). In this scenario, will LetsEncrypt create different certificates for me, or if it sees two identical certificate requests from the same account, will it give me identical tokens and an identical cert? (If it is the latter situation, then the order may have been finalized already by another worker)
Update: I think my last paragraph describes the situation that is happening. I tried making two orders with the same set of domains, but different CSRs, and I got back the same order URI. So I have two workers that are processing the same order in this situation.
This is confusing, shouldn’t I be getting a unique order ID back since I passed in different CSRs? Could this be a bug in Boulder?
Yes, exactly that. RFC 8555 7.1.6 describes an order changing status from "ready" to "processing" once a finalization request is received, and from "processing" to "valid" once the certificate is issued. Only "ready" orders can be finalized so after the first finalization request is received the order can't be finalized by additional concurrent requests.
So if they wanted to e.g. issue dual RSA and ECDSA certificates for the same domain, I guess @CertIssuer would have to finalize the first order before creating the second one.
Yup. Unfortunately you won’t be able to issue concurrently for the same set of domain names but with a different public key or CSR extensions. The two certificates would have to be processed serially.
Thank you for the detailed insight, this has helped me understand the issue quite well.
Would there be any drawbacks with considering a hash of the CSR alongside the unique set of domain names? (Meaning that separate orders for the same set of domains would get separate tokens and be validated independently from one another). I’m open to posting in the feature requests forum if that is more appropriate, but want to make sure I haven’t missed anything.