Questions about SCEP polling mode
ml16685 opened this issue · 4 comments
Hello,
Could you please advice about a few questions related to SCEP polling mode:
-
Do I correctly understand that as long as I execute sscep with the
same csr file (provided via -r option), tansaction Id for enroll will stay
the same, and it is in fact MD5 hash of the public key from the csr file? -
I need to implement the following polling scheme:
Initially there should be a PKCSReq and a number of CertPolls with a small retry interval.
If response is still Pending, the service should sleep for several hours and then resume polling.
What is the correct approach to resume polling after that several hours sleep?
As I understand, RFC 8894 advices to resume polling with a new PKCSReq
(section "5.2. Transactions with Errors").
But is it possible that SCEP servers will maintain transaction even for
several hours?
In this case it seems more rational to first try resume with CertPoll
and in case of Failure response to start a new PKCSReq.
Or it is not common for the servers to maintain long transactions
and starting a new PKCSReq is a more correct appoach anyway?
At least OpenXPKI expects that the same transaction ID be used, otherwise it is impossible to properly handle latency or delayed certificate issuance on the backend (e. g. if a certificate request has to be approved manually). If you retry with a different transaction ID the PKI will see a new initial enrollment which will also end up as a new pending request in addition to the previous one.
My take on this is to reuse the same transaction ID for a pending request while polling until the client receives the issued certificate or the client determines that the request has failed (e. g. after a few hours or days).
At least OpenXPKI expects that the same transaction ID be used, otherwise it is impossible to properly handle latency or delayed certificate issuance on the backend (e. g. if a certificate request has to be approved manually). If you retry with a different transaction ID the PKI will see a new initial enrollment which will also end up as a new pending request in addition to the previous one.
My take on this is to reuse the same transaction ID for a pending request while polling until the client receives the issued certificate or the client determines that the request has failed (e. g. after a few hours or days).
@mbartosch, Thank you for response. I will proceed with this approach then.
Also, regarding transaction Id value used by sscep for enroll. As I got from source ccode, it will remain the same as long as public key in csr file will be the same. Is that correct?
IIRC the code computes the TID from the public key via a hash. This is also suggested by the standard and good practice, IMO.
Ok, thank you.