Kompromittiertes Zertifikat widerrufen und per Re-Issue ersetzen

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 nutzen Sie 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, senden Sie 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 starten Sie 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 entnehmen Sie den geforderten DCV-Record und aktualisieren Sie 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üfen Sie 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'

Achten Sie besonders auf:

reissue.status
reissue.order_state
reissue.validation
certificate_pem_available

Schritt 5: Neues Zertifikat herunterladen

Sobald das Re-Issue abgeschlossen ist, holen Sie das Ersatz-Zertifikat über dieselbe Zertifikats-id ab und übergeben 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

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

Ergebnis

Mit diesem Ablauf reagieren Sie 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.