Open abunashir opened 7 years ago
@clintwilson we could't find a good way of locating a newly re-issued order/certificate. Could you help shine some light on this? Thanks!
Just to confirm the challenge you've got here: When you place a reissue request, it's difficult to determine when the new certificate has been issued so that it can be downloaded.
Does the Orders Lists filter for "reissue_processing" help with monitoring for a completed reissue? i.e.
@clintwilson the use case here is a bit different. We currently take advantage of DigiCert's "unlimited issuance" to issue multiple certificates for a hostname using different keys, like this:
The challenge we have is, in step 4, we can't figure out which certificate was created corresponding to $key_1 through $request_id_1.
Perhaps there have a method of doing so?
In step 1, are you sending a POST to /services/v2/order/certificate/$order_id/duplicate or to /services/v2/order/certificate/$order_id/reissue? In step 4, are you sending a GET to /services/v2/order/certificate/$order_id/duplicate and are you pulling out the certificates.id which corresponds to the largest certificates.sub_id value?
@clintwilson sorry for the delay in replying, obviously I missed it.
In step 1 we had the same issue with reissue and duplicate.
I didn't know we could use the certificates.sub_id
value to differentiate, however this doesn't solve the problem completely as race conditions of duplication could occur.
For example, duplicating with key-1 then with key-2 in a short period of time, the sub_id
does not tell which request generated which duplicated certificate.
And this issue is greatly helped by the new response type of #127 .
I've done some investigation here.
The only attribute that can be matched between a Request and a Certificate is the CSR content itself.
The request.date_processed
and certificate.date_created
are close, but are often not identical, e.g., request.date_processed
can be 2018-04-15T01:01:04+00:00
but certificate.date_created
can be 2018-04-15T01:01:02+00:00
. Notice that the certificate can be created before the request is "processed". We could match the minutes but probably not the seconds?
Using the CSR to match will fail if the same CSR is used to generate two duplicates within a short time.
@clintwilson would there be a better option of linking a particular request to a particular certificate?
I confirm that this is an ongoing problem - we can't reliably link a request to its generated certificate.
@abunashir Can you fix the way to find the reissued order?
@kwkwan, @ronaldtse: I'm not sure what would be the best possible solution for this, but do you think if we add a finder interface (ReissuedCertificateFinder
) like our duplicate certificate finder and find the one within one minute's duration (between created_at and date_processced) will help?
@abunashir we are not actually doing a "reissue", but a "duplicate". I actually thought the DuplicateCertificateFinder
was supposed to achieve this? i.e.:
duplicate -> get duplicate request -> find duplicated certificate
?
But if we're talking about "reissue", yes a finder interface would work 😉
@ronaldtse: I'm sorry but I'm not exactly sure what we need to do regarding this issue, we already have that functionality implemented for a duplicate certificate finder, does that solve our problem or should we add another interface?
cc: @kwkwan
ping @ronaldtse
We are working on a
CLI
, where we are automating the order reissuing process and download the reissued certificate and then provision it to our host, but the problem we have had is with finding out the correct reissued certificate.In the reissuing process, if we try to retrieve the status for the newly created request then it returns
approved
or another status, which does not clearly identify if that certificate has been issued.And the
order
node in the request provides the details for that request, but thestatus
always statesneeds_approval
although the request has already been approved or issued.Currently, we did some comparison of the
last_reissued_date
and dates to find out the reissued order but an easier interface would help.Reference: https://github.com/riboseinc/digicert/issues/117