TLS-Bestellung überwachen und bei Fehler abbrechen

Dieses Rezept ergänzt die eigentliche Zertifikatsbestellung um einen kontrollierten Überwachungs- und Abbruchpfad. Es ist besonders nützlich, wenn Sie Bestellungen automatisiert auslösen und hängende Aufträge nicht manuell nachverfolgen wollen.

Voraussetzungen

ein API-Key mit Zugriff auf TLS-Endpunkte
ein gültiger CSR
definierte Regeln, wann eine Bestellung als hängen geblieben oder fachlich ungültig gilt
ein Job oder Worker, der Statusabfragen wiederholt ausführen kann

Schritt 1: Zertifikatsauftrag anlegen

Die Bestellung liefert Ihnen die id, mit der Sie den gesamten weiteren Ablauf steuern.

curl --request POST \
  --url 'https://api.regfish.com/tls/certificate' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "sku": "RapidSSL",
  "common_name": "www.example.com",
  "csr": "-----BEGIN CERTIFICATE REQUEST-----\nMIIC...\n-----END CERTIFICATE REQUEST-----",
  "dcv_method": "dns-cname-token"
}
'

Wenn dieser Auftrag als explizite Verlängerung laufen soll, fügen Sie renewal_of_certificate_id hinzu. Monitoring, Timeout-Regeln und Cancel-Ablauf bleiben identisch, weil auch eine Verlängerung über denselben Endpunkt als eigene Bestellung angelegt wird.

Speichern Sie aus der Antwort mindestens:

id
status
order_state
eventuelle Validierungsdaten

Schritt 2: Status in Intervallen abfragen

Danach pollen Sie den Auftrag so lange, bis er ausgestellt, eindeutig fehlgeschlagen oder fachlich überfällig ist.

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

Typische Abbruchregeln sind zum Beispiel:

der Auftrag bleibt zu lange in pending
die benötigte Validierung wurde im erwarteten Zeitfenster nicht abgeschlossen
ein nachgelagerter Prozess entscheidet, dass der Auftrag nicht mehr benötigt wird

Mit dem aktuellen API sollten Sie außerdem mitlesen:

order_cancellable
order_cancellation_mode
order_cancellable_until

Schritt 3: Timeout oder Fehlerfall erkennen

Sobald Ihre Überwachungslogik entscheidet, dass der Auftrag nicht weiterlaufen soll, markieren Sie ihn intern als abzubrechen. Üblich ist hier eine Kombination aus Zeitgrenze, Statusbewertung und fachlichem Kontext.

Ein einfaches internes Entscheidungsmodell kann so aussehen:

{
  "certificate_id": "7K9QW3M2ZT8HJ",
  "maxPendingMinutes": 30,
  "cancelWhenStatusStill": "pending",
  "reason": "dcv-timeout"
}

Schritt 4: Auftrag stornieren

Im Fehler- oder Timeout-Fall storniert Ihr Workflow den Auftrag aktiv. So bleiben keine offenen Bestellungen im System hängen.

curl --request POST \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/cancel' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "note": "Cancelled automatically after DCV timeout in provisioning workflow"
}
'

Diesen Pfad nutzen Sie für noch pendende Aufträge. Wenn die gelesene Zertifikatsantwort stattdessen einen vollständigen DigiCert-Order-Cancel oder -Revoke signalisiert, verwenden Sie /tls/certificate/{certificate_id}/order-cancel.

curl --request POST \
  --url 'https://api.regfish.com/tls/certificate/7K9QW3M2ZT8HJ/order-cancel' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "comment": "Order revoked automatically after policy timeout"
}
'

Schritt 5: Storno nachverfolgen

Nach dem Cancel sollten Sie den Auftrag noch einmal lesen, damit Ihre interne Auftragslage und der externe Providerzustand konsistent bleiben.

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

Praxishinweise für produktive Abläufe

trennen Sie Bestellung, Polling und Storno in eigene Zustandsübergänge
speichern Sie die Begründung für das Canceln immer mit
vermeiden Sie Endlosschleifen, indem Sie ein klares Maximalalter für offene Bestellungen definieren
nutzen Sie Alarme nur für Ausnahmen, nicht für jeden Pending-Zustand
halten Sie Ihren Workflow idempotent, damit ein Cancel-Job sicher erneut laufen kann

Ergebnis

Mit diesem Ablauf wird aus der bloßen Zertifikatsbestellung ein kontrollierter Lifecycle mit sauberem Timeout- und Fehlerpfad. Dasselbe gilt für Bestellungen zur expliziten Verlängerung, die über renewal_of_certificate_id erzeugt werden.