Sophos Firewall Zertifikat per XML API erneuern und Dienste prüfen

Kürzere Laufzeiten öffentlich vertrauenswürdiger TLS-Zertifikate erhöhen den Aufwand für manuelle Erneuerungen. Das Zertifikat wird deshalb auf einem externen System ausgestellt, von einem geschützten Automationshost importiert, dem vorgesehenen Dienst zugewiesen und danach am echten Listener geprüft. Eine erfolgreiche Ausstellung bestätigt noch keinen Import; ein vorhandenes Zertifikatsobjekt bestätigt noch nicht, welches Zertifikat WebAdmin, Portal, WAF oder SMTP ausliefert.

Die XML-Felder für add und update stammen immer aus API help des eingesetzten SFOS-Builds. Das Identifikationsfeld für ein bestehendes Objekt, der Erhalt von Referenzen und das Verhalten nach Fehlern werden in einem Testlauf ermittelt. Der Artikel zeigt daher bewusst keine angeblich universelle Update-Nutzlast.

Der Ablauf in vier Phasen

Vorbereiten: CA-Berechtigungen, Validierungen, Automationshost, API-Zugriff und Rückweg klären.
Testen: Mit einem entbehrlichen Namen das lokale Add-/Update-Beispiel in eine versionsgebundene Multipart-Anfrage überführen und freigeben.
Erneuern: Zertifikat und Schlüssel prüfen, hochladen und den vorgesehenen Diensten zuweisen.
Abnehmen: Objektdatei und echten Listener prüfen, Betrieb überwachen und das alte Zertifikat erst später entfernen.

Warum die Laufzeiten eine robuste Automation verlangen

Die maximal zulässige Laufzeit öffentlich vertrauenswürdiger TLS-Zertifikate wird stufenweise kürzer. Gemäss den Baseline Requirements des CA/Browser Forum gelten für neu ausgestellte Zertifikate folgende Obergrenzen:

vor dem 15. März 2026: höchstens 398 Tage;
vom 15. März 2026 bis 14. März 2027: höchstens 200 Tage;
vom 15. März 2027 bis 14. März 2029: höchstens 100 Tage;
ab dem 15. März 2029: höchstens 47 Tage.

Auch der zulässige Wiederverwendungszeitraum für abgeschlossene Domain- oder IP-Validierungen verkürzt sich in denselben Stufen von 398 auf 200, 100 und schliesslich 10 Tage. Zertifikat und zugrunde liegende Validierung haben somit getrennte Fristen.

DigiCert stellt laut seinem aktuellen Hinweis zu kürzeren Laufzeiten seit dem 24. Februar 2026 öffentliche TLS-Zertifikate mit höchstens 199 Tagen Laufzeit aus. Betriebliche Grenzen von 99 beziehungsweise 46 Tagen sind erst für Anfang 2027 beziehungsweise Anfang 2029 angekündigt; die genauen Umstellungstermine können sich noch ändern. Die Automation überwacht daher das tatsächlich ausgestellte notAfter, statt eine feste Jahreslaufzeit anzunehmen.

Integriertes Let’s Encrypt und externe CA trennen

Die in SFOS integrierte Let’s-Encrypt-Funktion ist ein eigener, von der Firewall geführter Ablauf. Sie ist kein generischer ACME-Client für DigiCert und lässt sich nicht einfach auf eine DigiCert-ACME-URL umstellen. Für den eingebauten Ablauf ist Let’s Encrypt Zertifikate auf Sophos Firewall einrichten der passende Weg.

Bei einer externen öffentlichen CA läuft die Ausstellung auf einem dafür geeigneten System. Erst das fertige Zertifikat wird über die XML API an SFOS übertragen.

CA-neutrale Voraussetzungen zuordnen

Vor der Einrichtung müssen bei der gewählten CA diese Punkte geklärt sein:

Produktberechtigung und zulässige Zertifikatstypen;
Bestellung, Subscription oder anderer Zahlungsweg;
Erstellung, Gültigkeit und Rotation der ACME- oder API-Zugangsdaten;
unterstützte DCV-Methode für jeden bestellten Namen;
bei OV/EV die nötige Organisationsvalidierung;
Zertifikats-, Domainvalidierungs- und Organisationsvalidierungsfristen.

Die Bezeichnungen und Freigabeschritte unterscheiden sich je nach Anbieter. Die folgenden Kontodetails sind deshalb ein konkretes DigiCert-Beispiel, keine allgemeine CA-Vorgabe.

DigiCert-Beispiel: Konto und ACME vorbereiten

In CertCentral muss die Automationsfunktion für das betreffende Konto aktiviert sein. Danach unterscheiden sich Einrichtung und Freigabe nach Kontomodell:

Bei Enterprise-, Partner- und älteren Nicht-Subscription-Konten kann nur ein CertCentral-Administrator die ACME Directory URL erstellen. Er kann die fertigen Zugangsdaten anschliessend einem eng berechtigten Dienstkonto für den laufenden Betrieb übergeben.
Für Enterprise- und andere Non-Subscription-Konten muss die automatische Freigabe von Zertifikatsanträgen aktiviert sein; ohne sie schlagen ACME-Anträge standardmässig fehl.
Subscription Accounts benötigen diese Einstellung zur automatischen Antragsfreigabe nicht. Die verfügbaren Produkte und der Subscription-Status müssen dennoch passen.

Damit bleiben die weitreichenden Rechte zur Erstellung der Zugangsdaten vom späteren Automationskonto getrennt. Vor dem ersten Auftrag zusätzlich Produktberechtigung, Zahlungsweg sowie Zuordnung der ACME Directory URL und des External Account Binding zum richtigen Konto und Produkt prüfen. Eine klar verantwortliche Person verwaltet Erstellung, Rotation und Notfallersatz der Zugangsdaten.

ACME-Zugangsdaten gehören in einen geschützten Geheimnisspeicher. Sie werden weder in ein Repository noch in ein Shell-Skript, Ticket, Wiki-Beispiel oder einen Postman-Export geschrieben.

DigiCert-Beispiel: DCV bei DV, OV und EV

Bei einem DV-Zertifikat führt DigiCert die Domain Control Validation für jede ACME-Bestellung neu aus; eine frühere DCV wird nicht vorvalidiert oder wiederverwendet. Der Automationshost muss die gewählte Challenge bei jeder Erneuerung erfüllen können.

Bei OV- und EV-Zertifikaten setzt eine unbeaufsichtigte ACME-Ausstellung eine vorab validierte Organisation voraus. Zusätzlich muss der Domainstatus gültig sein. DigiCert verwendet zurzeit eine wiederverwendbare OV-/EV-Domainvalidierung von 199 Tagen; die Organisationsvalidierung für öffentliche OV-Zertifikate ist zurzeit 397 Tage wiederverwendbar. Beide Fristen werden getrennt vom Zertifikatsablauf überwacht.

Für ein Wildcard-Zertifikat wie *.example.com ist DNS-01 der typische Validierungsweg. Der DNS-API-Zugang sollte nur die benötigte Zone oder den benötigten Record bearbeiten dürfen.

Sicheren Automationshost aufbauen

Der Automationshost verarbeitet zeitweise den privaten Schlüssel, CA-Zugangsdaten und ein schreibberechtigtes SFOS-Passwort. Er gehört in eine geschützte Management-Umgebung und nicht auf ein allgemeines Admin-Notebook oder eine beliebige CI-Ausführungsumgebung.

Mindestanforderungen sind:

gehärtetes, aktualisiertes Betriebssystem mit klar verantwortlicher Person;
feste Quell-IP oder eng begrenztes Management-Netz;
ausgehender Zugriff nur zu CA, DNS-API und vorgesehenen Firewalls;
getrennte Zugangsdaten für CA, DNS und jede Firewall beziehungsweise klar abgegrenzte Firewall-Gruppe;
Geheimnisspeicher statt Umgebungsvariablen, Diagnoseausgaben, Kommandozeilenparameter oder Klartextdateien;
restriktive Dateirechte und temporäres Arbeitsverzeichnis auf verschlüsseltem Speicher;
keine privaten Schlüssel, Passwörter oder vollständigen XML-Anfragen in Protokollen;
nachvollziehbare Auftrags-ID, Ziel-Firewall, Zertifikatsname und Ergebnis ohne geheime Inhalte;
Uhrzeitsynchronisation und Alarmierung bei wiederholtem Fehler oder zu kleiner Restlaufzeit.

Falls der private Schlüssel verschlüsselt an SFOS übertragen wird, sollte das Importpasswort aus Kompatibilitätsgründen höchstens 30 Zeichen lang sein. Die SFOS-GUI-Hilfe nennt diese Obergrenze, während die API-Hilfe je nach Build 4 bis 128 Zeichen beschreibt. Die Begrenzung auf 30 Zeichen dient ausschliesslich der Kompatibilität und ist keine allgemeine Empfehlung für Passwortlängen. Das zufällige Passwort gilt nur für diesen Schlüssel und wird geschützt transportiert.

Die Härtung von Quelle, Dienstkonto, Device Access und API-Rechten beschreibt Sophos Firewall XML API Zugriff absichern. Unter SFOS 22 wird in Administration > API access nur der IP Host des Automationssystems unter Allowed IP hosts zugelassen. Auf älteren Versionen befindet sich die API-Konfiguration an einem anderen Menüpfad.

Testlauf vor der produktiven Erneuerung

Der Testlauf verwendet einen entbehrlichen Namen wie test-fw.example.com, ein separates Zertifikatsobjekt und einen Listener, dessen Unterbruch vertretbar ist. Er wird nach relevanten SFOS- oder Automationsupdates wiederholt.

Verhalten des eingesetzten Builds ermitteln

Mit den Tests wird das Verhalten des konkreten Builds ermittelt; sie ersetzen keine Herstellerzusage. Zu prüfen und zu protokollieren sind:

genauer SFOS-Build und verwendete lokale API help;
exakte add- und update-Felder sowie das Identifikationsfeld des bestehenden Objekts;
Ergebnis beim erneuten Senden derselben Anfrage und nach einem abgebrochenen Upload;
Verarbeitung einer Zertifikatsdatei mit Leaf und Intermediate-Zertifikaten sowie resultierende CA-Objekte;
tatsächlich ausgelieferte Kette;
Erhalt oder Verlust von WebAdmin-, Portal-, WAF- und SMTP-Referenzen;
nötige Listener-Aktivierung oder allfälliger Dienstneustart;
bei HA die Übernahme von Zertifikat, privatem Schlüssel und Zuweisung sowie die Auslieferung nach Failover.

Eine Fullchain-Datei gilt nicht ungeprüft als unterstützt. Ebenso darf die Automation weder Idempotenz noch Referenzerhalt oder eine sichere automatische Wiederholung nach Fehlern voraussetzen.

Vom lokalen Add-/Update-Beispiel zur Anfrage

So entsteht für den installierten Build eine konkrete, aber nicht fälschlich universelle Anfrage:

In der lokalen API help der Ziel-Firewall zu System > Certificates > Certificate > Add Certificate / Update Certificate wechseln. Die Beispielkonfiguration und Parameterbeschreibung für genau diesen Build speichern.
Für den ersten Fall den dokumentierten add-Wrapper verwenden. Für den zweiten Fall das dort gezeigte update und dessen Identifikationsfeld übernehmen. Weder Operationsattribut noch Objektkennung aus einem anderen Build kopieren.
Im Beispiel nur die Umgebungswerte ersetzen: API-Anmeldung aus dem Geheimnisspeicher, Objektname test-public-cert, Aktion für den Zertifikatsupload, Zertifikatsformat, Zertifikatsdateiname, Private-Key-Dateiname und gegebenenfalls das Importpasswort. Nicht benötigte Beispielzweige entfernen, aber Elementnamen und Verschachtelung unverändert lassen.
Die resultierende XML-Anfrage lokal als flüchtiges reqxml erzeugen. Die beiden Dateinamen im XML müssen exakt zu den hochgeladenen Dateien passen.
In Postman oder der verwendeten HTTP-Bibliothek POST an den folgenden Endpoint und multipart/form-data wählen:
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Genau drei Multipart-Teile anlegen: den in der lokalen Hilfe genannten Datei-Part für das Zertifikat, den dort genannten Datei-Part für den privaten Schlüssel und das Textfeld reqxml. Die ersten beiden Part-Namen werden nicht geraten; ihr aktueller Name und die Dateinamen werden aus dem Beispiel des Ziel-Builds übernommen.
Zuerst add, danach mit einem neu ausgestellten Testzertifikat update ausführen. Zusätzlich eine ungültige Anfrage in der Testumgebung senden und den Zustand vor einer Wiederholung zurücklesen.
Freigegeben wird die Anfrage erst, wenn <Response> und <Status> den erwarteten Erfolg melden, genau das vorgesehene Objekt geändert wurde, keine unerwarteten CA-Objekte entstanden sind, die Dienstreferenz wie protokolliert reagiert und der externe Listener nach Zuweisung das neue Zertifikat samt gültiger Kette liefert. Bei HA gehört ein kontrollierter Failover dazu.

Anhand der Ergebnisse wird die Anfrage für genau diesen Build erstellt, getestet und intern freigegeben. Die drei Part-Namen, die XML-Vorlage, erwartete Statuswerte und Abbruchbedingungen werden gemeinsam versioniert, ohne Zugangsdaten oder Schlüssel abzulegen.

Zertifikat vor dem Upload prüfen

Die folgenden Beispiele verwenden diese Austauschwerte:

Dienst-FQDN: vpn.example.com
SFOS-Objektname: public-vpn-example-com
Leaf-Zertifikat: vpn.example.com.pem
privater Schlüssel: vpn.example.com.key
Intermediate-Bundle: intermediates.pem
vertrauenswürdiges Root-Bundle: trust-roots.pem
externer HTTPS-Port: 443

Zuerst Zertifikatsdaten lesen:

openssl x509 -in vpn.example.com.pem -noout -subject -issuer -serial -dates -ext subjectAltName -fingerprint -sha256

Aussteller, Gültigkeitszeitraum, SANs und SHA-256-Fingerprint müssen zur Bestellung passen. Danach prüfen, ob Zertifikat und privater Schlüssel dasselbe Schlüsselpaar bilden, ohne den Schlüssel auszugeben:

(
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl x509 -in vpn.example.com.pem -pubkey -noout > "$tmpdir/cert-public-key.pem" &&
    openssl pkey -in vpn.example.com.key -pubout > "$tmpdir/key-public-key.pem" &&
    cmp "$tmpdir/cert-public-key.pem" "$tmpdir/key-public-key.pem"
)

cmp bleibt bei identischen öffentlichen Schlüsseln ohne Ausgabe. Bei einer Abweichung wird abgebrochen. Ein verschlüsselter privater Schlüssel fordert das Passwort interaktiv an; in der Automation kommt es aus dem Geheimnisspeicher und erscheint weder im Prozessaufruf noch im Protokoll.

Die vorgesehene Kette wird gegen den eigenen Vertrauensspeicher geprüft:

openssl verify -CAfile trust-roots.pem -untrusted intermediates.pem vpn.example.com.pem

trust-roots.pem enthält die in der eigenen Umgebung vertrauten Root-CAs, intermediates.pem die zur Ausstellung gehörenden Intermediate-CAs. Erfolgreich ist die Prüfung nur mit der Ausgabe vpn.example.com.pem: OK; jede andere Ausgabe stoppt den Upload.

Zertifikat per XML API übertragen

Prüfungen vor dem Upload

Vor dem Schreiben Ziel-Firewall, SFOS-Build, Objektname und Dienste mit der genehmigten Änderung abgleichen. Ein aktuelles Sophos Firewall Backup, der alternative Managementzugang und das bisherige Zertifikatsobjekt müssen verfügbar sein. Mit demselben Host und Dienstkonto zuerst eine ungefährliche Leseabfrage ausführen. Dateirechte und lokale Zertifikatsprüfungen dürfen keine Fehler zeigen.

Anfrage senden und Antwort bewerten

Die Automation sendet die im Testlauf freigegebene Multipart-Anfrage. Zertifikat und privater Schlüssel werden als Dateien übertragen; reqxml wird zur Laufzeit erzeugt und danach verworfen. Der Client verwendet den zum Firewall-Zertifikat passenden FQDN, validiert dessen CA und bricht bei Hostnamen- oder Zertifikatsfehlern ab. curl -k oder eine vergleichbare Abschaltung der TLS-Prüfung ist unzulässig.

Ein HTTP-Status 200 oder Send successful bestätigt nur den Transport. Die Automation wertet im XML mindestens das zur Operation gehörende <Response>-Element und dessen <Status> anhand der im Testlauf freigegebenen Werte aus. Bei Timeout, unvollständiger Antwort oder negativem Status liest sie zuerst den Objektzustand zurück oder stoppt zur manuellen Klärung; sie wiederholt die Schreibanfrage nicht ungeprüft.

Objekt und heruntergeladene Datei kontrollieren

Unter Certificates > Certificates das Zielobjekt suchen. In der GUI werden die dort tatsächlich angebotenen Angaben geprüft, insbesondere Objektname, Private-Key-Status, Trusted, die beim Darüberfahren sichtbaren Werte Subject, Issuer und Purpose sowie unerwartete zusätzliche Zertifikats- oder CA-Objekte.

Seriennummer, SANs, Ablaufdatum und SHA-256-Fingerprint werden nicht als garantierte GUI-Felder vorausgesetzt. Das Zielzertifikat über die Download-Aktion von SFOS exportieren und die heruntergeladene Datei prüfen:

openssl x509 -in downloaded-vpn.example.com.pem -noout -serial -dates -issuer -subject -ext subjectAltName -fingerprint -sha256

Diese Werte müssen mit der vor dem Upload geprüften Datei übereinstimmen. Der grüne Trusted-Status allein beweist weder die richtige Dienstzuweisung noch eine vollständige Listener-Kette. Formate, Kette und GUI-Import erklärt Zertifikate auf Sophos Firewall importieren und zuweisen.

Zertifikat dem Dienst zuweisen

Import und Zuweisung sind getrennte Änderungen. Ein neues Objekt wird ausdrücklich dem gewünschten Dienst zugewiesen. Bei einer Aktualisierung wird der im Testlauf bestätigte Weg verwendet und der tatsächliche Referenzerhalt nach dem Lauf kontrolliert.

WebAdmin und Portale

Unter Administration > Admin and user settings > Admin console and end-user interaction gilt das Feld Certificate gemeinsam für WebAdmin Console, User Portal, VPN Portal, Captive Portal sowie SPX Registration und Reply Portal. Das Zertifikat muss alle tatsächlich verwendeten Namen als SAN enthalten. Nach Apply jeden FQDN und Port einzeln prüfen; eine bestehende Admin-Sitzung und ein alternativer lokaler Managementweg bleiben offen.

WAF

Bei einer WAF-Veröffentlichung wird das Zertifikat in der jeweiligen Regel unter Rules and policies > Firewall im Feld HTTPS certificate ausgewählt. Domain, SNI, Listen Port und SAN müssen zusammenpassen. Beim Speichern werden die Web-Server-Protection-Regeln neu gestartet; bestehende Verbindungen können abbrechen. Ob auch der Austausch eines bereits referenzierten Zertifikats einen Reload auslöst, muss mit dem eingesetzten Build im Testlauf geprüft werden.

SMTP TLS

Im MTA-Modus liegt die Auswahl unter Email > General settings > SMTP TLS configuration im Feld TLS certificate. Nach Apply werden STARTTLS und gegebenenfalls implizites TLS getrennt geprüft. VPN- und weitere Zertifikatsverwendungen können eigene Zuweisungen besitzen; ein identischer Name bedeutet nicht, dass sie automatisch wechseln.

Extern mit SNI und richtigem Port validieren

Zuerst Kette und Hostname vom realistischen externen Prüfhost kontrollieren:

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts -verify_hostname vpn.example.com -verify_return_error </dev/null

Erwartet werden die benötigten Intermediate-Zertifikate und Verification: OK. -servername sendet SNI; FQDN und Port werden durch den echten Dienst ersetzt.

Fingerprint, Seriennummer und weitere Leaf-Daten lassen sich mit einem zweiten, ausführbaren Schritt aus derselben Listener-Konfiguration lesen:

(
  set -o pipefail
  tmpdir=$(mktemp -d)
  trap 'rm -rf -- "$tmpdir"' EXIT
  openssl s_client -connect vpn.example.com:443 -servername vpn.example.com -showcerts \
    -verify_hostname vpn.example.com -verify_return_error </dev/null 2>"$tmpdir/s_client.log" |
    openssl x509 -out "$tmpdir/leaf.pem" &&
  openssl x509 -in "$tmpdir/leaf.pem" -noout -serial -fingerprint -sha256 -dates -issuer -subject -ext subjectAltName
)

Seriennummer, SHA-256-Fingerprint, Laufzeit, Issuer und SANs müssen mit dem freigegebenen Zertifikat übereinstimmen. Anschliessend die Anwendung selbst prüfen, etwa Anmeldung am Portal, WAF-Healthcheck oder eine andere ungefährliche End-to-End-Funktion. Ein vorgeschalteter Load Balancer, CDN oder Reverse Proxy kann ein anderes Zertifikat terminieren; der Testpunkt muss daher zur beabsichtigten SFOS-Funktion passen.

SMTP mit STARTTLS benötigt einen eigenen Aufruf:

openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com -verify_hostname mail.example.com -verify_return_error </dev/null

Für implizites TLS auf Port 465 entfällt -starttls smtp. Auch hier werden Kette und Hostname mit Verification: OK bestätigt; die Leaf-Daten können mit dem vorherigen Extraktionsmuster und den angepassten Verbindungsoptionen gelesen werden. Danach den tatsächlichen Mailfluss prüfen.

Wartungsfenster, Rollback und HA

Wartungsfenster vorbereiten

Der erste produktive Lauf sowie Änderungen an Anfrage, SFOS-Build, CA-Produkt oder Kettenzusammenstellung erfolgen in einem Wartungsfenster. Das bisherige Objekt bleibt verfügbar; betroffene Zuweisungen, alternativer Managementzugang sowie die Verantwortlichen für Rückweg und externe Prüfung sind bekannt.

Rollback-Strategie wählen

Bei einem neuen Objekt ist der klarste Rückweg, im betroffenen Dienst wieder das alte Zertifikat auszuwählen und den Listener erneut extern zu testen. Das alte Objekt wird deshalb nicht im selben Lauf gelöscht.

Bei einer Aktualisierung des bestehenden Objekts gilt ausschliesslich der im Testlauf bestätigte Rückweg. Ist das sichere Wiedereinspielen des vorherigen Inhalts nicht nachgewiesen, wird konservativ ein separates neues Objekt angelegt und anschliessend ausdrücklich zugewiesen.

HA separat testen

SFOS synchronisiert in einem HA-Cluster grundsätzlich Konfiguration vom Primary zum Auxiliary. Zertifikat, privater Schlüssel und Dienstzuweisung müssen dennoch auf beiden Knoten beziehungsweise am gemeinsamen Dienst geprüft werden. Danach folgt ein kontrollierter Failover mit externer Listener-Prüfung. Erst ein bestandener Test gibt den Ablauf für HA frei.

Überwachung und wiederkehrender Betrieb

Die Automation muss Fehler und ausbleibende Erneuerungen rechtzeitig melden. Laufend überwacht werden:

verbleibende Tage des Zertifikats am externen Listener und nächstes CA-Erneuerungsfenster;
DCV-Status und bei OV/EV zusätzlich Organisationsvalidierung;
letzter erfolgreicher CA-Auftrag und SFOS-Upload;
erwarteter und tatsächlich ausgelieferter Fingerprint;
API-Fehler, uneindeutige Antworten und abgebrochene Läufe;
ungeplante neue Zertifikats- oder CA-Objekte;
Ablauf und Rotation von Zugangsdaten;
bei HA der letzte bestandene Failover-Test.

Der Alarm muss genügend Zeit für CA-/DCV-Dauer, interne Reaktion, Wartungsfenster und Rückweg lassen. Nach einem erfolgreichen Wechsel bleibt das alte Zertifikat während der definierten Beobachtungszeit bestehen. Temporäre Zertifikats-, Schlüssel- und XML-Dateien werden kontrolliert gelöscht; dauerhaft gespeicherte Nachweisdaten enthalten nur nicht geheime Metadaten.

Fehlerbehebung nach Symptom

CA stellt kein neues Zertifikat aus

Beim jeweiligen Anbieter Produktberechtigung, Kontostatus, Zahlungsweg und DCV prüfen. Im DigiCert-Beispiel zusätzlich Automation sowie die kontomodellspezifische automatische Antragsfreigabe kontrollieren. Bei OV/EV müssen Organisation und Domain gültig sein. DNS-01-Fehler am autoritativen öffentlichen DNS prüfen, nicht nur am lokalen Resolver.

XML API ist nicht erreichbar

Quell-IP aus Sicht der Firewall, Allowed IP hosts, Device Access, Routing, Admin-Port und Firewall-Zertifikat prüfen. Der Test muss vom wirklichen Automationshost erfolgen.

HTTP-Anfrage gelingt, Zertifikat wird aber nicht aktualisiert

<Response> und <Status> statt nur den HTTP-Code prüfen. Danach Objektname, Dateiformat, zulässige Passwortlänge und die build-spezifischen Felder mit der lokalen API-Hilfe vergleichen. Unter Diagnostics > Troubleshooting logs helfen apiparser.log, validation.log und validationError.log; vor dem Teilen alle Zugangsdaten entfernen. Bei unklarem Zustand zuerst das Zertifikatsobjekt herunterladen und prüfen, statt die Schreibanfrage ungeprüft zu wiederholen.

Objekt ist neu, der Dienst zeigt aber das alte Zertifikat

Dienstzuweisung, WAF-Regel, gemeinsame Zertifikatsauswahl für WebAdmin und Portale oder SMTP-Konfiguration prüfen. Danach mit SNI am richtigen Port testen und einen vorgeschalteten TLS-Endpunkt ausschliessen.

Zertifikat ist nicht `Trusted` oder die Kette ist unvollständig

Issuer des Leaf-Zertifikats mit den installierten Intermediate-CAs vergleichen. Das im Testlauf bestätigte Importverfahren verwenden und die vom Listener gesendete Kette mit -showcerts kontrollieren.

Nach Update oder Failover erscheint wieder das alte Zertifikat

Feststellen, welcher Knoten und Listener antwortet. Dann heruntergeladenen Objekt-Fingerprint, Dienstreferenz und HA-Zustand vergleichen. Bei einer Abweichung den bestätigten Rückweg ausführen und die Automation stoppen.

Abnahmecheckliste

Die produktive Erneuerung ist nur freigegeben, wenn alle Punkte erfüllt sind:

CA-Berechtigung, Zahlung, DCV und gegebenenfalls Organisationsvalidierung sind gültig.
Build, lokale API-Hilfe und Multipart-Anfrage entsprechen dem bestandenen Testlauf.
Lokale Zertifikats-, Schlüssel- und Kettenprüfung war erfolgreich.
<Response> und <Status> melden den erwarteten Erfolg; genau das Zielobjekt wurde geändert.
Die heruntergeladene Objektdatei hat erwartete Seriennummer, SANs, Laufzeit und SHA-256-Fingerprint; privater Schlüssel und Trusted-Status sind korrekt und es entstanden keine unerwarteten Objekte.
Jeder reale FQDN und Port liefert mit SNI das neue Zertifikat, die erwartete Kette und Verification: OK; der zugehörige Dienst funktioniert.
Bei HA wurde der kontrollierte Failover samt externer Prüfung bestanden.
Überwachung erkennt neues Ablaufdatum und erfolgreiches Ergebnis; das alte Zertifikat bleibt bis zum Ende der Beobachtungszeit als Rückweg erhalten.