Sophos Firewall-certificaat via XML API vernieuwen en services controleren

Kortere looptijden van openbaar vertrouwde TLS-certificaten verhogen de werklast voor handmatige vernieuwingen. Daarom wordt het certificaat op een extern systeem uitgegeven, vanaf een beveiligde automatiseringshost geïmporteerd, aan de beoogde service toegewezen en vervolgens op de daadwerkelijke listener gecontroleerd. Een geslaagde uitgifte bevestigt nog geen import; de aanwezigheid van een certificaatobject bevestigt nog niet welk certificaat WebAdmin, Portal, WAF of SMTP aanbiedt.

De XML-velden voor add en update zijn altijd afkomstig uit API help van de gebruikte SFOS-build. Het identificatieveld voor een bestaand object, het behoud van referenties en het gedrag na fouten worden in een testrun bepaald. Daarom toont dit artikel bewust geen zogenaamd universele updatepayload.

De procedure in vier fasen

Voorbereiden: CA-rechten, validaties, automatiseringshost, API-toegang en terugvalmogelijkheid regelen.
Testen: Met een niet-kritieke naam het lokale add-/updatevoorbeeld omzetten in een versiegebonden multipart-aanvraag en deze goedkeuren.
Vernieuwen: Certificaat en sleutel controleren, uploaden en aan de beoogde services toewijzen.
Valideren: Objectbestand en daadwerkelijke listener controleren, de werking bewaken en het oude certificaat pas later verwijderen.

Waarom de looptijden robuuste automatisering vereisen

De maximaal toegestane looptijd van openbaar vertrouwde TLS-certificaten wordt stapsgewijs korter. Volgens de Baseline Requirements van het CA/Browser Forum gelden voor nieuw uitgegeven certificaten de volgende bovengrenzen:

vóór 15 maart 2026: maximaal 398 dagen;
van 15 maart 2026 tot en met 14 maart 2027: maximaal 200 dagen;
van 15 maart 2027 tot en met 14 maart 2029: maximaal 100 dagen;
vanaf 15 maart 2029: maximaal 47 dagen.

Ook de toegestane hergebruikstermijn voor voltooide domein- of IP-validaties wordt in dezelfde stappen verkort van 398 naar 200, 100 en uiteindelijk 10 dagen. Het certificaat en de onderliggende validatie hebben dus afzonderlijke termijnen.

Volgens de actuele mededeling van DigiCert over kortere looptijden geeft DigiCert sinds 24 februari 2026 openbare TLS-certificaten uit met een looptijd van maximaal 199 dagen. Operationele grenzen van respectievelijk 99 en 46 dagen zijn pas aangekondigd voor begin 2027 en begin 2029; de precieze omschakeldatums kunnen nog veranderen. De automatisering bewaakt daarom de daadwerkelijk uitgegeven notAfter in plaats van uit te gaan van een vaste jaarlooptijd.

Geïntegreerd Let’s Encrypt en externe CA gescheiden houden

De in SFOS geïntegreerde Let’s Encrypt-functie is een afzonderlijke procedure die door de firewall wordt beheerd. Deze functie is geen generieke ACME-client voor DigiCert en kan niet simpelweg naar een DigiCert-ACME-URL worden omgeschakeld. Voor de ingebouwde procedure is Let’s Encrypt-certificaten op Sophos Firewall configureren de juiste aanpak.

Bij een externe openbare CA vindt de uitgifte plaats op een daarvoor geschikt systeem. Pas het voltooide certificaat wordt via de XML API naar SFOS overgedragen.

CA-neutrale vereisten vaststellen

Vóór de configuratie moeten bij de gekozen CA de volgende punten zijn opgehelderd:

productrechten en toegestane certificaattypen;
bestelling, abonnement of andere betaalwijze;
aanmaak, geldigheid en rotatie van ACME- of API-toegangsgegevens;
ondersteunde DCV-methode voor elke bestelde naam;
bij OV/EV de vereiste organisatievalidatie;
termijnen van certificaat-, domein- en organisatievalidatie.

De benamingen en goedkeuringsstappen verschillen per aanbieder. De volgende accountgegevens zijn daarom een concreet DigiCert-voorbeeld en geen algemene CA-vereiste.

DigiCert-voorbeeld: account en ACME voorbereiden

In CertCentral moet de automatiseringsfunctie voor het betreffende account zijn geactiveerd. Daarna verschillen de configuratie en goedkeuring per accountmodel:

Bij Enterprise-, Partner- en oudere niet-Subscription-accounts kan alleen een CertCentral-beheerder de ACME Directory URL aanmaken. Vervolgens kan deze de voltooide toegangsgegevens voor dagelijks gebruik overdragen aan een serviceaccount met strikt beperkte rechten.
Voor Enterprise- en andere Non-Subscription-accounts moet de automatische goedkeuring van certificaataanvragen zijn geactiveerd; zonder deze instelling mislukken ACME-aanvragen standaard.
Subscription Accounts hebben deze instelling voor automatische aanvraaggoedkeuring niet nodig. De beschikbare producten en de abonnementsstatus moeten desondanks kloppen.

Zo blijven de uitgebreide rechten om de toegangsgegevens aan te maken gescheiden van het latere automatiseringsaccount. Controleer vóór de eerste opdracht bovendien de productrechten en betaalwijze, en of de ACME Directory URL en External Account Binding aan het juiste account en product zijn gekoppeld. Een duidelijk aangewezen verantwoordelijke beheert de aanmaak, rotatie en noodvervanging van de toegangsgegevens.

ACME-toegangsgegevens horen thuis in een beveiligde geheimenopslag. Ze worden niet opgenomen in een repository, shellscript, ticket, wikivoorbeeld of Postman-export.

DigiCert-voorbeeld: DCV bij DV, OV en EV

Bij een DV-certificaat voert DigiCert de Domain Control Validation voor elke ACME-bestelling opnieuw uit; een eerdere DCV wordt niet vooraf gevalideerd of hergebruikt. De automatiseringshost moet bij elke vernieuwing de gekozen challenge kunnen uitvoeren.

Bij OV- en EV-certificaten vereist onbeheerde ACME-uitgifte een vooraf gevalideerde organisatie. Daarnaast moet de domeinstatus geldig zijn. DigiCert hanteert momenteel een herbruikbare OV-/EV-domeinvalidatie van 199 dagen; de organisatievalidatie voor openbare OV-certificaten is momenteel 397 dagen herbruikbaar. Beide termijnen worden afzonderlijk van de certificaatvervaldatum bewaakt.

Voor een wildcardcertificaat zoals *.example.com is DNS-01 de gebruikelijke validatiemethode. De DNS-API-toegang mag alleen de benodigde zone of het benodigde record kunnen wijzigen.

Een veilige automatiseringshost opzetten

De automatiseringshost verwerkt tijdelijk de privésleutel, CA-toegangsgegevens en een SFOS-wachtwoord met schrijfrechten. Deze host hoort thuis in een beveiligde beheeromgeving en niet op een algemene beheerlaptop of in een willekeurige CI-uitvoeringsomgeving.

De minimumvereisten zijn:

een gehard en bijgewerkt besturingssysteem met een duidelijk aangewezen verantwoordelijke;
een vast bron-IP-adres of strikt beperkt beheernetwerk;
alleen uitgaande toegang tot de CA, DNS-API en beoogde firewalls;
afzonderlijke toegangsgegevens voor CA, DNS en elke firewall, of voor een duidelijk afgebakende firewallgroep;
geheimenopslag in plaats van omgevingsvariabelen, diagnostische uitvoer, opdrachtregelparameters of plattetekstbestanden;
beperkte bestandsrechten en een tijdelijke werkmap op versleutelde opslag;
geen privésleutels, wachtwoorden of volledige XML-aanvragen in logboeken;
een traceerbare opdracht-ID, doelfirewall, certificaatnaam en resultaat zonder geheime inhoud;
tijdsynchronisatie en waarschuwingen bij herhaalde fouten of een te korte resterende looptijd.

Als de privésleutel versleuteld naar SFOS wordt overgedragen, mag het importwachtwoord vanwege compatibiliteit bij voorkeur niet langer zijn dan 30 tekens. De SFOS-GUI-help noemt deze bovengrens, terwijl de API-help afhankelijk van de build 4 tot 128 tekens beschrijft. De beperking tot 30 tekens dient uitsluitend de compatibiliteit en is geen algemene aanbeveling voor wachtwoordlengtes. Het willekeurige wachtwoord geldt alleen voor deze sleutel en wordt beveiligd overgedragen.

De beveiliging van de bron, het serviceaccount, Device Access en de API-rechten wordt beschreven in Toegang tot de Sophos Firewall XML API beveiligen. Onder SFOS 22 wordt in Administration > API access alleen de IP Host van het automatiseringssysteem onder Allowed IP hosts toegestaan. In oudere versies bevindt de API-configuratie zich onder een ander menupad.

Testrun vóór de productievernieuwing

De testrun gebruikt een niet-kritieke naam zoals test-fw.example.com, een afzonderlijk certificaatobject en een listener waarvan een onderbreking acceptabel is. De run wordt na relevante SFOS- of automatiseringsupdates herhaald.

Het gedrag van de gebruikte build vaststellen

Met de tests wordt het gedrag van de specifieke build vastgesteld; ze vormen geen toezegging van de fabrikant. Het volgende moet worden gecontroleerd en vastgelegd:

de exacte SFOS-build en de gebruikte lokale API help;
de precieze velden voor add en update, en het identificatieveld van het bestaande object;
het resultaat wanneer dezelfde aanvraag opnieuw wordt verzonden en na een afgebroken upload;
de verwerking van een certificaatbestand met leaf- en intermediate-certificaten, en de daaruit voortkomende CA-objecten;
de daadwerkelijk aangeboden keten;
behoud of verlies van WebAdmin-, Portal-, WAF- en SMTP-referenties;
de vereiste listeneractivering of een eventuele herstart van de service;
bij HA de overname van certificaat, privésleutel en toewijzing, en het aanbieden ervan na een failover.

Een fullchain-bestand wordt niet zonder controle als ondersteund beschouwd. Evenmin mag de automatisering uitgaan van idempotentie, referentiebehoud of een veilige automatische herhaling na fouten.

Van het lokale add-/updatevoorbeeld naar de aanvraag

Zo ontstaat voor de geïnstalleerde build een concrete aanvraag zonder ten onrechte te suggereren dat deze universeel is:

Ga in de lokale API help van de doelfirewall naar System > Certificates > Certificate > Add Certificate / Update Certificate. Sla de voorbeeldconfiguratie en parameterbeschrijving voor precies deze build op.
Gebruik voor het eerste geval de gedocumenteerde add-wrapper. Neem voor het tweede geval de daar getoonde update en het bijbehorende identificatieveld over. Kopieer noch het bewerkingsattribuut, noch de object-ID uit een andere build.
Vervang in het voorbeeld alleen de omgevingswaarden: API-aanmelding uit de geheimenopslag, objectnaam test-public-cert, actie voor de certificaatupload, certificaatindeling, bestandsnaam van het certificaat, bestandsnaam van de Private Key en, indien nodig, het importwachtwoord. Verwijder overbodige voorbeeldvertakkingen, maar laat elementnamen en de geneste structuur ongewijzigd.
Maak de resulterende XML-aanvraag lokaal aan als tijdelijke reqxml. De twee bestandsnamen in de XML moeten exact overeenkomen met de geüploade bestanden.
Kies in Postman of de gebruikte HTTP-bibliotheek POST naar het volgende endpoint en selecteer multipart/form-data:
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Maak precies drie multipartdelen: het in de lokale help genoemde bestandsdeel voor het certificaat, het daar genoemde bestandsdeel voor de privésleutel en het tekstveld reqxml. De namen van de eerste twee parts worden niet gegokt; hun actuele naam en de bestandsnamen worden overgenomen uit het voorbeeld van de doelbuild.
Voer eerst add uit en daarna update met een nieuw uitgegeven testcertificaat. Verzend daarnaast in de testomgeving een ongeldige aanvraag en lees de status terug voordat een aanvraag wordt herhaald.
De aanvraag wordt pas goedgekeurd wanneer <Response> en <Status> het verwachte succes melden, precies het beoogde object is gewijzigd, er geen onverwachte CA-objecten zijn ontstaan, de servicereferentie reageert zoals vastgelegd en de externe listener na de toewijzing het nieuwe certificaat met een geldige keten aanbiedt. Bij HA hoort daar een gecontroleerde failover bij.

Aan de hand van de resultaten wordt de aanvraag specifiek voor deze build opgesteld, getest en intern goedgekeurd. De drie partnamen, het XML-sjabloon, de verwachte statuswaarden en de afbreekvoorwaarden worden gezamenlijk onder versiebeheer geplaatst, zonder toegangsgegevens of sleutels op te slaan.

Certificaat vóór de upload controleren

De volgende voorbeelden gebruiken deze vervangingswaarden:

service-FQDN: vpn.example.com
SFOS-objectnaam: public-vpn-example-com
leaf-certificaat: vpn.example.com.pem
privésleutel: vpn.example.com.key
intermediate-bundel: intermediates.pem
vertrouwde rootbundel: trust-roots.pem
externe HTTPS-poort: 443

Lees eerst de certificaatgegevens uit:

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

Uitgever, geldigheidsduur, SAN’s en SHA-256-vingerafdruk moeten overeenkomen met de bestelling. Controleer vervolgens of het certificaat en de privésleutel hetzelfde sleutelpaar vormen, zonder de sleutel weer te geven:

(
  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"
)

Bij identieke openbare sleutels geeft cmp niets weer. Bij een verschil wordt de procedure afgebroken. Voor een versleutelde privésleutel wordt interactief om het wachtwoord gevraagd; in de automatisering is dit afkomstig uit de geheimenopslag en verschijnt het noch in de procesaanroep, noch in het logboek.

De beoogde keten wordt gecontroleerd aan de hand van de eigen vertrouwensopslag:

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

trust-roots.pem bevat de root-CA’s die in de eigen omgeving worden vertrouwd, intermediates.pem de intermediate-CA’s die bij de uitgifte horen. De controle is alleen succesvol bij de uitvoer vpn.example.com.pem: OK; elke andere uitvoer stopt de upload.

Certificaat via de XML API overdragen

Controles vóór de upload

Vergelijk vóór het schrijven de doelfirewall, SFOS-build, objectnaam en services met de goedgekeurde wijziging. Een actuele Sophos Firewall-back-up, de alternatieve beheertoegang en het bestaande certificaatobject moeten beschikbaar zijn. Voer met dezelfde host en hetzelfde serviceaccount eerst een ongevaarlijke leesaanvraag uit. De bestandsrechten en lokale certificaatcontroles mogen geen fouten opleveren.

Aanvraag verzenden en antwoord beoordelen

De automatisering verzendt de multipart-aanvraag die tijdens de testrun is goedgekeurd. Certificaat en privésleutel worden als bestanden overgedragen; reqxml wordt tijdens de uitvoering aangemaakt en daarna verwijderd. De client gebruikt de FQDN die bij het firewallcertificaat hoort, valideert de CA ervan en breekt af bij fouten in de hostnaam of het certificaat. curl -k of een vergelijkbare uitschakeling van de TLS-controle is niet toegestaan.

Een HTTP-status 200 of Send successful bevestigt alleen het transport. De automatisering beoordeelt in de XML minimaal het bij de bewerking horende <Response>-element en de bijbehorende <Status> aan de hand van de tijdens de testrun goedgekeurde waarden. Bij een time-out, onvolledig antwoord of negatieve status leest de automatisering eerst de objectstatus terug of stopt voor handmatige controle; de schrijfaanvraag wordt niet zonder controle herhaald.

Object en gedownload bestand controleren

Zoek onder Certificates > Certificates naar het doelobject. Controleer de gegevens die daar daadwerkelijk in de GUI worden aangeboden, met name de objectnaam, Private Key-status, Trusted, de bij aanwijzen weergegeven waarden Subject, Issuer en Purpose, en onverwachte aanvullende certificaat- of CA-objecten.

Er wordt niet van uitgegaan dat serienummer, SAN’s, vervaldatum en SHA-256-vingerafdruk gegarandeerde GUI-velden zijn. Exporteer het doelcertificaat via de downloadactie van SFOS en controleer het gedownloade bestand:

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

Deze waarden moeten overeenkomen met het bestand dat vóór de upload is gecontroleerd. Alleen de groene status Trusted bewijst noch de juiste servicetoewijzing, noch een volledige listenerketen. Indelingen, keten en GUI-import worden uitgelegd in Certificaten op Sophos Firewall importeren en toewijzen.

Certificaat aan de service toewijzen

Import en toewijzing zijn afzonderlijke wijzigingen. Een nieuw object wordt expliciet aan de gewenste service toegewezen. Bij een update wordt de tijdens de testrun bevestigde methode gebruikt en wordt na de uitvoering gecontroleerd of de referenties daadwerkelijk behouden zijn.

WebAdmin en portalen

Onder Administration > Admin and user settings > Admin console and end-user interaction geldt het veld Certificate gezamenlijk voor WebAdmin Console, User Portal, VPN Portal, Captive Portal, SPX Registration en Reply Portal. Het certificaat moet alle werkelijk gebruikte namen als SAN bevatten. Controleer na Apply elke FQDN en poort afzonderlijk; houd een bestaande beheersessie en een alternatieve lokale beheerroute open.

WAF

Bij een WAF-publicatie wordt het certificaat in de betreffende regel onder Rules and policies > Firewall in het veld HTTPS certificate geselecteerd. Domain, SNI, Listen Port en SAN moeten op elkaar aansluiten. Bij het opslaan worden de Web Server Protection-regels opnieuw gestart; bestaande verbindingen kunnen worden verbroken. Of ook het vervangen van een certificaat waarnaar al wordt verwezen een reload activeert, moet voor de gebruikte build tijdens de testrun worden gecontroleerd.

SMTP TLS

In de MTA-modus bevindt de selectie zich onder Email > General settings > SMTP TLS configuration in het veld TLS certificate. Na Apply worden STARTTLS en, indien van toepassing, impliciete TLS afzonderlijk gecontroleerd. VPN en andere certificaattoepassingen kunnen eigen toewijzingen hebben; een identieke naam betekent niet dat ze automatisch worden omgeschakeld.

Extern valideren met SNI en de juiste poort

Controleer eerst de keten en hostnaam vanaf een realistische externe testhost:

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

De benodigde intermediate-certificaten en Verification: OK worden verwacht. -servername verzendt SNI; vervang FQDN en poort door die van de daadwerkelijke service.

De vingerafdruk, het serienummer en andere leaf-gegevens kunnen met een tweede uitvoerbare stap uit dezelfde listenerconfiguratie worden gelezen:

(
  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
)

Serienummer, SHA-256-vingerafdruk, looptijd, Issuer en SAN’s moeten overeenkomen met het goedgekeurde certificaat. Controleer vervolgens de toepassing zelf, bijvoorbeeld door aan te melden bij het portaal, een WAF-healthcheck uit te voeren of een andere ongevaarlijke end-to-end-functie te gebruiken. Een voorliggende load balancer, CDN of reverse proxy kan een ander certificaat termineren; het testpunt moet daarom aansluiten op de beoogde SFOS-functie.

SMTP met STARTTLS vereist een afzonderlijke aanroep:

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

Voor impliciete TLS op poort 465 wordt -starttls smtp weggelaten. Ook hier worden de keten en hostnaam bevestigd met Verification: OK; de leaf-gegevens kunnen met het voorgaande extractiepatroon en de aangepaste verbindingsopties worden uitgelezen. Controleer daarna de daadwerkelijke e-mailstroom.

Onderhoudsvenster, rollback en HA

Onderhoudsvenster voorbereiden

De eerste productierun en wijzigingen aan de aanvraag, SFOS-build, het CA-product of de samenstelling van de keten vinden plaats in een onderhoudsvenster. Het bestaande object blijft beschikbaar; de betreffende toewijzingen, alternatieve beheertoegang en de verantwoordelijken voor de terugval en externe controle zijn bekend.

Rollbackstrategie kiezen

Bij een nieuw object is de duidelijkste terugvalmogelijkheid om in de betreffende service opnieuw het oude certificaat te selecteren en de listener nogmaals extern te testen. Het oude object wordt daarom niet in dezelfde run verwijderd.

Bij een update van het bestaande object geldt uitsluitend de tijdens de testrun bevestigde terugvalprocedure. Als niet is aangetoond dat de vorige inhoud veilig opnieuw kan worden geïmporteerd, wordt conservatief een afzonderlijk nieuw object aangemaakt en vervolgens expliciet toegewezen.

HA afzonderlijk testen

SFOS synchroniseert in een HA-cluster in principe de configuratie van de Primary naar de Auxiliary. Het certificaat, de privésleutel en de servicetoewijzing moeten desondanks op beide knooppunten of op de gemeenschappelijke service worden gecontroleerd. Daarna volgt een gecontroleerde failover met een externe listenercontrole. Pas na een geslaagde test wordt de procedure voor HA goedgekeurd.

Bewaking en terugkerend beheer

De automatisering moet fouten en uitblijvende vernieuwingen tijdig melden. Doorlopend worden bewaakt:

resterende dagen van het certificaat op de externe listener en het volgende CA-vernieuwingsvenster;
DCV-status en bij OV/EV bovendien de organisatievalidatie;
laatste geslaagde CA-opdracht en SFOS-upload;
verwachte en daadwerkelijk aangeboden vingerafdruk;
API-fouten, onduidelijke antwoorden en afgebroken runs;
ongeplande nieuwe certificaat- of CA-objecten;
vervaldatum en rotatie van toegangsgegevens;
bij HA de laatste geslaagde failovertest.

De waarschuwing moet voldoende tijd laten voor de duur van CA/DCV, interne respons, het onderhoudsvenster en de terugval. Na een geslaagde omschakeling blijft het oude certificaat gedurende de vastgestelde observatieperiode bestaan. Tijdelijke certificaat-, sleutel- en XML-bestanden worden gecontroleerd verwijderd; permanent opgeslagen bewijsgegevens bevatten uitsluitend niet-geheime metadata.

Probleemoplossing per symptoom

CA geeft geen nieuw certificaat uit

Controleer bij de betreffende aanbieder de productrechten, accountstatus, betaalwijze en DCV. Controleer in het DigiCert-voorbeeld bovendien Automation en de accountspecifieke automatische aanvraaggoedkeuring. Bij OV/EV moeten de organisatie en het domein geldig zijn. Controleer DNS-01-fouten op de autoritatieve openbare DNS en niet alleen op de lokale resolver.

XML API is niet bereikbaar

Controleer het bron-IP-adres vanuit het perspectief van de firewall, Allowed IP hosts, Device Access, routing, de Admin Port en het firewallcertificaat. De test moet vanaf de daadwerkelijke automatiseringshost worden uitgevoerd.

HTTP-aanvraag slaagt, maar certificaat wordt niet bijgewerkt

Controleer <Response> en <Status> in plaats van alleen de HTTP-code. Vergelijk daarna de objectnaam, bestandsindeling, toegestane wachtwoordlengte en buildspecifieke velden met de lokale API-help. Onder Diagnostics > Troubleshooting logs kunnen apiparser.log, validation.log en validationError.log helpen; verwijder vóór het delen alle toegangsgegevens. Download en controleer bij een onduidelijke status eerst het certificaatobject in plaats van de schrijfaanvraag zonder controle te herhalen.

Object is nieuw, maar de service toont het oude certificaat

Controleer de servicetoewijzing, WAF-regel, gezamenlijke certificaatselectie voor WebAdmin en portalen, of de SMTP-configuratie. Test daarna met SNI op de juiste poort en sluit een voorliggend TLS-eindpunt uit.

Certificaat is niet `Trusted` of de keten is onvolledig

Vergelijk de Issuer van het leaf-certificaat met de geïnstalleerde intermediate-CA’s. Gebruik de tijdens de testrun bevestigde importmethode en controleer met -showcerts de keten die door de listener wordt verzonden.

Na update of failover verschijnt weer het oude certificaat

Stel vast welk knooppunt en welke listener antwoordt. Vergelijk daarna de gedownloade objectvingerafdruk, de servicereferentie en de HA-status. Voer bij een afwijking de bevestigde terugvalprocedure uit en stop de automatisering.

Acceptatiechecklist

De productievernieuwing is alleen goedgekeurd als aan alle punten is voldaan:

CA-rechten, betaling, DCV en, indien van toepassing, organisatievalidatie zijn geldig.
Build, lokale API-help en multipart-aanvraag komen overeen met de geslaagde testrun.
De lokale controle van certificaat, sleutel en keten is geslaagd.
<Response> en <Status> melden het verwachte succes; precies het doelobject is gewijzigd.
Het gedownloade objectbestand heeft het verwachte serienummer, de verwachte SAN’s, looptijd en SHA-256-vingerafdruk; de privésleutel en status Trusted zijn correct en er zijn geen onverwachte objecten ontstaan.
Elke werkelijke FQDN en poort levert met SNI het nieuwe certificaat, de verwachte keten en Verification: OK; de bijbehorende service werkt.
Bij HA is de gecontroleerde failover inclusief externe controle geslaagd.
De bewaking herkent de nieuwe vervaldatum en het geslaagde resultaat; het oude certificaat blijft tot het einde van de observatieperiode als terugvalmogelijkheid behouden.