Plötzliche intermittierende TLS-Fehler seit 16. März 2026 – ohne Änderung an der Konfiguration

Dirk Mueller 25 Zuverlässigkeitspunkte
2026-03-17T12:45:59.4766667+00:00

Umgebung: Azure API Management (Custom Domain mit Wildcard-Zertifikat, Starfield CA)

Ausgangssituation

Unser APIM läuft seit Jahren stabil mit einem Wildcard-Zertifikat auf einer Custom Domain. Am 10. März 2026 haben wir im Rahmen der regulären Zertifikatserneuerung ein neues PFX unter Custom Domains eingespielt. Das APIM funktionierte danach problemlos – bis zum 16. März 2026 gegen 16:00 Uhr MEZ.

Problem

Seit dem 16. März 2026, ~16:00 Uhr MEZ treten intermittierende TLS-Verifikationsfehler auf. Ca. 50% der Verbindungen schlagen fehl, der Rest funktioniert normal. An der APIM-Konfiguration wurde zwischen dem 10. März und dem 16. März nichts geändert.

Der genaue Fehlerzeitpunkt fällt zusammen mit dem Ende eines Azure Resource Manager Incidents (Mitigation 14:55 UTC = 15:55 MEZ), was auf einen internen Azure-seitigen Node-Neustart oder ein Redeployment als Auslöser hindeutet.

Die Fehlerdiagnose ergab, dass ein Teil der Gateway-Nodes eine unvollständige TLS-Chain ausliefert (nur Leaf, kein Intermediate), während andere Nodes die Chain korrekt ausliefern. Das erklärt das intermittierende Muster.

Reproduzierbarer Test:

i=1; while true; do
  printf "Request %d %s: " "$i" "$(date '+%H:%M:%S')"
  OUTPUT=$(echo "Q" | openssl s_client -connect api.example.com:443 \
    -servername api.example.com 2>&1)
  if echo "$OUTPUT" | grep -q "depth=1"; then
    CHAIN="Chain: Leaf + Intermediate OK"
  else
    CHAIN="Chain: Nur Leaf – UNVOLLSTÄNDIG"
  fi
  VERIFY=$(echo "$OUTPUT" | grep "Verify return code" | sed 's/.*Verify return code: //')
  printf "%s | Verify: %s\n" "$CHAIN" "$VERIFY"
  sleep 29
  i=$((i+1))
done

Typische Ausgabe:

Request 1 12:47:26: Chain: Leaf + Intermediate OK | Verify: 0 (ok)
Request 2 12:47:55: Chain: Nur Leaf – UNVOLLSTÄNDIG | Verify: 21 (unable to verify the first certificate)
Request 3 12:48:24: Chain: Leaf + Intermediate OK | Verify: 0 (ok)

Bisheriger Lösungsversuch

Am 17. März 2026 haben wir ein neues PFX mit vollständiger Chain (Leaf + Intermediate) erstellt und unter Custom Domains hochgeladen. Nach dem Upload liefern weiterhin ~50% der Requests eine unvollständige Chain. Ein erneutes Speichern des Zertifikats hat ebenfalls keine Verbesserung gebracht.

Fragen

  1. Kann ein Azure-internes Ereignis (z.B. Node-Neustart durch einen Plattform-Incident) dazu führen, dass einzelne APIM-Gateway-Nodes ein Zertifikat ohne vollständige Chain ausliefern, obwohl die Konfiguration unverändert ist?
  2. Warum propagiert das neu hochgeladene Zertifikat nach über einer Stunde immer noch nicht auf alle Nodes?
  3. Gibt es eine Möglichkeit, den Rollout manuell zu erzwingen oder den Zertifikatsstatus pro Node einzusehen?
Azure API Management
Azure API Management

Ein Azure-Dienst, der eine hybride Multi-Cloud-Verwaltungsplattform für APIs bereitstellt

Antwort, die vom Frageautor angenommen wurde
Rakesh Mishra 11,350 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator
2026-03-17T14:51:36.9733333+00:00

Hallo Dirk,

Eure Diagnose trifft den Kern des Problems genau, und Eure Vermutung ist korrekt. Hier sind direkte Antworten auf Eure zwei Zusatzfragen. Bitte teilen Sie mir in den Kommentaren mit, ob es hilfreich ist.

F1: Ignoriert Azure APIM ein hochgeladenes PFX, wenn Fingerprint und Seriennummer identisch sind?

Dieses Verhalten ist von Microsoft nicht explizit dokumentiert, ist aber die logische Konsequenz daraus, wie APIM Zertifikat-Identitäten behandelt. Die ARM-Ressourcenschicht verwaltet Zertifikate anhand ihres Thumbprints — wenn ein PFX mit demselben Fingerprint hochgeladen wird, erkennt die Control Plane keine Zustandsänderung und gibt keinen neuen Propagations-Befehl an die Gateway-Nodes aus. Das deckt sich mit Euren Monitoring-Daten, bei denen das Intermediate nur sporadisch aus dem Cache auftaucht — nicht weil das neue PFX tatsächlich übernommen wurde.

Hinzu kommt der zeitliche Zusammenhang: Der Azure-Incident am 16. März hat wahrscheinlich dazu geführt, dass einige Nodes ihren TLS-Zustand neu aus dem gespeicherten PFX (dem ursprünglichen Leaf-only-File) geladen haben, während andere Nodes weiterhin eine gecachte In-Memory-Chain mit Intermediate ausgeliefert haben. Euer Re-Upload mit identischem Fingerprint hat diesen Split-Zustand nicht behoben, weil kein Rollout ausgelöst wurde.

F2: Gibt es einen Mechanismus, um einen Rollout auch bei identischem Fingerprint zu erzwingen?

Bei direktem PFX-Upload gibt es keinen dokumentierten Weg, eine erneute Propagation zu erzwingen, wenn der Fingerprint unverändert ist. Folgende Optionen stehen zur Verfügung:

Option A — Zertifikatseintrag löschen und neu anlegen (schnellste Abhilfe): Löscht das Zertifikat unter Sicherheit > Zertifikate im Portal und fügt es neu hinzu. Selbst mit demselben PFX zwingt das Löschen des Zertifikat-Objekts APIM dazu, es als neuen Eintrag zu behandeln. Die Propagation der Zertifikatszuweisung kann je nach Deployment-Größe 15 Minuten oder länger dauern. Dieser Schritt sollte alle Nodes zum Neuladen der vollständigen Chain veranlassen.

Option B — Temporäres Ersatzzertifikat verwenden: Ladet ein beliebiges gültiges PFX mit einem anderen Fingerprint hoch (z. B. ein kurzlebiges Self-Signed-Zertifikat für dieselbe Domain), speichert die Custom-Domain-Bindung darauf, wartet auf die Propagation und wechselt dann zurück zum echten Zertifikat. Beide Speichervorgänge lösen jeweils eine vollständige Propagation aus.

Option C — Migration zu Key Vault (die nachhaltige Lösung): Microsoft empfiehlt Key-Vault-Zertifikate, da Updates in API Management automatisch innerhalb von vier Stunden rotiert werden und zusätzlich jederzeit manuell über das Azure-Portal oder die Management-REST-API sofort aktualisiert werden können. Mit Key Vault lässt sich ein sofortiger erzwungener Refresh ohne Wartezeit über die REST API auslösen:

http

POST https://management.azure.com/subscriptions/{sub}/resourceGroups/{rg}/providers/
  Microsoft.ApiManagement/service/{apim}/certificates/{certId}/refreshSecret
  ?api-version=2024-05-01

Dieser Endpunkt löst eine sofortige Aktualisierung des Key-Vault-gesicherten Zertifikats im gesamten Service aus. Wichtig: Stellt beim Einrichten der Key-Vault-Referenz sicher, dass der Secret-Identifier keine Version enthält — andernfalls funktioniert die automatische Rotation nicht und es wird dauerhaft nur die zum Zeitpunkt der Einrichtung hinterlegte Version verwendet.

Empfohlene Sofortmaßnahmen:

  1. Löscht den aktuellen Zertifikatseintrag unter Sicherheit > Zertifikate im Azure-Portal
  2. Fügt dasselbe PFX erneut hinzu (mit vollständiger Chain: Leaf + Intermediate)
  3. Speichert die Custom-Domain-Bindung neu, sodass sie auf das neu hinzugefügte Zertifikat verweist
  4. Überwacht den Zustand mit Eurem openssl-Loop — innerhalb von ~15–20 Minuten sollten 100 % der Verbindungen eine vollständige Chain liefern
  5. Eröffnet ein Support-Ticket bei Microsoft mit Verweis auf den ARM-Incident vom 16. März — der Support kann bestätigen, ob der Node-Neustart den Split-Chain-Zustand verursacht hat, und kann ggf. eine plattformseitige Neusynchronisierung erzwingen, falls Option A das Problem nicht vollständig behebt

Referenzen:

Hinweis: Diese Antwort wurde mithilfe von KI-Systemen erstellt.

War diese Antwort hilfreich?

Eine Person fand diese Antwort hilfreich.

0 zusätzliche Antworten

Sortieren nach: Am hilfreichsten
Am hilfreichsten Neueste Älteste

Ihre Antwort

Antworten können von Fragestellenden als „Angenommen“ und von Moderierenden als „Empfohlen“ gekennzeichnet werden, wodurch Benutzende wissen, dass diese Antwort das Problem des Fragestellenden gelöst hat.