Zum Inhalt springen

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 nutzt du stattdessen create-certificate mit renewal_of_certificate_id.

  • 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

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.

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

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.

Terminal-Fenster
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

Abschnitt betitelt „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.

Terminal-Fenster
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

Abschnitt betitelt „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.

Terminal-Fenster
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

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.

Terminal-Fenster
curl --request GET \
--url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/download/pem' \
--header 'x-api-key: YOUR_API_KEY' \
--output 'replacement-7K9QW3M2ZT8HJ.pem'
  • 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

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.