This recipe covers a security-critical flow: an existing certificate must be revoked while a replacement needs to be rolled out quickly. With the new re-issue endpoint, that replacement now belongs on the same order instead of being modeled as a completely new certificate order.

The distinction matters here: this is not a renewal flow. For a planned move into a new order or contract period, use create-certificate with renewal_of_certificate_id instead.

Prerequisites

• an API key with access to the TLS and DNS endpoints
• the certificate id of the compromised certificate
• a newly generated private key and a new CSR
• DNS access for domain control validation
• a downstream deployment step for the replacement certificate

Step 1: Revoke the existing certificate

If a key has been compromised or a certificate must be replaced, start by sending the revocation request with a suitable reason to the provider.

curl --request POST \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/revoke' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "comment": "Automatic revocation after key compromise incident",
  "revocation_reason": "key_compromise"
}
'

Step 2: Trigger the re-issue with a new CSR

Immediately after that, trigger the re-issue on the same certificate id. For compromised keys, a new CSR is essential so the replacement certificate does not depend on the old key material.

curl --request POST \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/reissue' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIC...NEW...\n-----END CERTIFICATE REQUEST-----",
  "dcv_method": "dns-cname-token",
  "comments": "Automatic reissue after key compromise incident"
}
'

The original certificate id stays the same. That is the key difference compared with the previous reorder flow.

Step 3: Update the DCV DNS record for the re-issue

Take the required DCV record from the re-issue response or from response.reissue.validation.dns_records and update the existing _dnsauth entry, preferably through PATCH /dns/rr.

curl --request PATCH \
  --url 'https://api.regfish.com/dns/rr' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "CNAME",
  "name": "_dnsauth.example.com",
  "data": "0123456789abcdef.dcv.digicert.com.",
  "ttl": 300
}
'

If the DCV record does not exist yet, the workflow falls back to POST /dns/rr for this step.

Step 4: Monitor re-issue status on the same certificate id

Then poll the same certificate order until the re-issue has been issued and the replacement certificate is ready for download.

curl --request GET \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ' \
  --header 'x-api-key: YOUR_API_KEY'

Pay close attention to:

• reissue.status
• reissue.order_state
• reissue.validation
• certificate_pem_available

Step 5: Download the new certificate

Once the re-issue has completed, download the replacement certificate through the same certificate id and pass it into the next deployment step.

curl --request GET \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/download/pem' \
  --header 'x-api-key: YOUR_API_KEY' \
  --output 'replacement-7K9QW3M2ZT8HJ.pem'

Practical notes for production workflows

• always use a new key and CSR for the re-issue
• separate revocation, re-issue, DCV, and deployment into explicit workflow steps
• document which certificate id was revoked and then replaced through re-issue
• automate the DCV step so rotation remains reliable under time pressure
• verify after deployment that no system is still serving the old certificate

Result

This workflow responds to compromise not only with revocation, but with a complete and traceable replacement on the same order. That is exactly where the new re-issue endpoint is a better fit than creating a separate replacement order.