Dieses Rezept deckt einen sicherheitskritischen Ablauf ab: Ein vorhandenes Zertifikat muss widerrufen werden, gleichzeitig soll aber schnell Ersatz beschafft und ausgerollt werden. Mit dem neuen Re-Issue-Endpunkt geschieht der Ersatz jetzt sinnvollerweise auf derselben Bestellung statt über eine komplett neue Zertifikatsorder.

Wichtig zur Abgrenzung: Das ist kein Verlängerungsfall. Für die planbare Verlängerung unter Anrechnung der Restlaufzeit in eine neue Bestellung oder Vertragsperiode nutzt du stattdessen create-certificate mit renewal_of_certificate_id.

Voraussetzungen

• ein API-Key mit Zugriff auf TLS- und DNS-Endpunkte
• die Zertifikats-id des kompromittierten Zertifikats
• ein neu erzeugter privater Schlüssel und ein neuer CSR
• DNS-Zugriff für die Domain-Control-Validation
• ein nachgelagerter Deployment-Schritt für das Ersatz-Zertifikat

Schritt 1: Bestehendes Zertifikat widerrufen

Wenn ein Schlüssel kompromittiert ist oder ein Zertifikat ausgetauscht werden muss, sendest du zuerst den Widerruf mit einer passenden Begründung an den 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"
}
'

Schritt 2: Re-Issue mit neuem CSR auslösen

Direkt danach startest du das Re-Issue auf derselben Zertifikats-id. Für kompromittierte Schlüssel ist ein neuer CSR entscheidend, damit das neue Zertifikat nicht auf dem alten Schlüsselmaterial basiert.

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"
}
'

Die ursprüngliche Zertifikats-id bleibt dabei erhalten. Das ist der wesentliche Unterschied zur früheren Neubestellung.

Schritt 3: DCV-DNS-Record für das Re-Issue aktualisieren

Aus der Re-Issue-Antwort oder aus response.reissue.validation.dns_records entnimmst du den geforderten DCV-Record und aktualisierst den bestehenden _dnsauth-Eintrag bevorzugt per 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
}
'

Falls der DCV-Record noch nicht existiert, fällt der Workflow für diesen Schritt auf POST /dns/rr zurück.

Schritt 4: Re-Issue-Status auf derselben Zertifikats-id überwachen

Danach prüfst du dieselbe Zertifikatsbestellung regelmäßig, bis das Re-Issue ausgestellt ist und das neue Zertifikat zur Ausgabe bereitsteht.

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

Achte besonders auf:

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

Schritt 5: Neues Zertifikat herunterladen

Sobald das Re-Issue abgeschlossen ist, holst du das Ersatz-Zertifikat über dieselbe Zertifikats-id ab und übergibst es an den nächsten Deployment-Schritt.

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

Praxishinweise für produktive Abläufe

• nutze für das Re-Issue immer einen neuen Schlüssel und einen neuen CSR
• trenne Widerruf, Re-Issue, DCV und Deployment in nachvollziehbare Schritte
• dokumentiere, welche Zertifikats-id widerrufen und anschließend per Re-Issue ersetzt wurde
• halte den DCV-Schritt automatisiert, damit Rotation auch unter Zeitdruck stabil bleibt
• prüfe nach dem Deployment aktiv, dass keine Systeme mehr das alte Zertifikat ausliefern

Ergebnis

Mit diesem Ablauf reagierst du auf eine Kompromittierung nicht nur mit einem Widerruf, sondern mit einer vollständigen, nachvollziehbaren Ersetzung des Zertifikats auf derselben Bestellung. Genau dafür passt der neue Re-Issue-Endpunkt wesentlich besser als eine komplette Neubestellung.