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.
Voraussetzungen
Abschnitt betitelt „Voraussetzungen“- ein API-Key mit Zugriff auf TLS- und DNS-Endpunkte
- die Zertifikats-
iddes 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
Abschnitt betitelt „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
Abschnitt betitelt „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
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.
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.
curl --request GET \ --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ' \ --header 'x-api-key: YOUR_API_KEY'Achte besonders auf:
reissue.statusreissue.order_statereissue.validationcertificate_pem_available
Schritt 5: Neues Zertifikat herunterladen
Abschnitt betitelt „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
Abschnitt betitelt „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-
idwiderrufen 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
Abschnitt betitelt „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.