Issues with finding a reissued order

[abunashir]

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 the status always states needs_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: #117

[ronaldtse]

@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!

[clintwilson]

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.

1. Place reissue request for $order_id
2. Approve reissue request
3. Ping https://www.digicert.com/services/v2/order/certificate?filters[status][0]=reissue_processing&filters[order_id]=$order_id
4. Once page.total=0, the reissue is complete

[ronaldtse]

@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:

1. Place reissue request for $order_id using $key_1, get $request_id_1
2. Approve reissue request for $request_id_1
3. Wait for $request_id_1 to be issued
4. Find certificate that was created by $request_id_1 through listing duplicate certificates of $order_id
5. Rinse and repeat with $key_2, ...

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?

[clintwilson]

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?

[ronaldtse]

@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.

[ronaldtse]

And this issue is greatly helped by the new response type of #127 .

[kwkwan]

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?

[ronaldtse]

I confirm that this is an ongoing problem - we can't reliably link a request to its generated certificate.

[kwkwan]

@abunashir Can you fix the way to find the reissued order?

[abunashir]

@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?

[ronaldtse]

@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

?

[ronaldtse]

But if we're talking about "reissue", yes a finder interface would work 😉

[abunashir]

@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

[abunashir]

ping @ronaldtse