Renouveler un certificat Sophos Firewall via l’API XML et vérifier les services

La réduction de la durée de validité des certificats TLS publiquement reconnus augmente la charge liée aux renouvellements manuels. Le certificat est donc émis sur un système externe, importé depuis un hôte d’automatisation protégé, attribué au service prévu, puis vérifié sur le listener réel. Une émission réussie ne confirme pas que l’importation a abouti ; la présence d’un objet certificat ne confirme pas encore quel certificat WebAdmin, le portail, la WAF ou SMTP présente.

Les champs XML pour add et update proviennent toujours de l’API help du build SFOS utilisé. Le champ d’identification d’un objet existant, la conservation des références et le comportement après une erreur sont déterminés lors d’un test. C’est pourquoi cet article ne présente volontairement aucune charge utile de mise à jour prétendument universelle.

La procédure en quatre phases

Préparer : clarifier les autorisations de la CA, les validations, l’hôte d’automatisation, l’accès API et la procédure de retour arrière.
Tester : avec un nom non essentiel, transformer l’exemple local d’ajout et de mise à jour en une requête multipart liée à la version, puis la valider.
Renouveler : vérifier le certificat et la clé, les uploader et les attribuer aux services prévus.
Valider : vérifier le fichier de l’objet et le listener réel, surveiller le fonctionnement et ne supprimer l’ancien certificat que plus tard.

Pourquoi la durée de validité exige une automatisation robuste

La durée maximale autorisée des certificats TLS publiquement reconnus diminue progressivement. Selon les Baseline Requirements du CA/Browser Forum, les limites suivantes s’appliquent aux nouveaux certificats émis :

avant le 15 mars 2026 : 398 jours au maximum ;
du 15 mars 2026 au 14 mars 2027 : 200 jours au maximum ;
du 15 mars 2027 au 14 mars 2029 : 100 jours au maximum ;
à partir du 15 mars 2029 : 47 jours au maximum.

La période de réutilisation autorisée des validations de domaine ou d’adresse IP terminées diminue elle aussi selon les mêmes paliers, de 398 à 200, puis 100 et enfin 10 jours. Le certificat et la validation sous-jacente ont donc des échéances distinctes.

Selon son avis actuel concernant la réduction des durées de validité, DigiCert émet depuis le 24 février 2026 des certificats TLS publics d’une durée maximale de 199 jours. Les limites opérationnelles de 99 et 46 jours ne sont annoncées que pour le début de 2027 et le début de 2029 respectivement ; les dates exactes de transition peuvent encore changer. L’automatisation surveille donc la valeur notAfter réellement émise au lieu de supposer une durée annuelle fixe.

Distinguer l’intégration Let’s Encrypt d’une CA externe

La fonction Let’s Encrypt intégrée à SFOS constitue une procédure distincte, pilotée par le pare-feu. Ce n’est pas un client ACME générique pour DigiCert et il n’est pas possible de simplement la faire pointer vers une URL ACME de DigiCert. Pour la procédure intégrée, Configurer des certificats Let’s Encrypt sur Sophos Firewall est la méthode appropriée.

Avec une CA publique externe, l’émission s’effectue sur un système adapté à cet usage. Le certificat finalisé n’est transféré vers SFOS via l’API XML qu’ensuite.

Recenser les prérequis indépendants de la CA

Avant la mise en place, les points suivants doivent être clarifiés auprès de la CA choisie :

autorisation d’utiliser le produit et types de certificats permis ;
commande, abonnement ou autre mode de paiement ;
création, validité et rotation des identifiants ACME ou API ;
méthode DCV prise en charge pour chaque nom commandé ;
validation d’organisation requise pour les certificats OV/EV ;
échéances du certificat, de la validation de domaine et de la validation d’organisation.

Les désignations et les étapes d’autorisation varient selon le fournisseur. Les détails de compte ci-dessous constituent donc un exemple concret pour DigiCert, et non une exigence générale applicable à toutes les CA.

Exemple DigiCert : préparer le compte et ACME

Dans CertCentral, la fonction d’automatisation doit être activée pour le compte concerné. La configuration et l’autorisation diffèrent ensuite selon le modèle de compte :

Pour les comptes Enterprise, Partner et les anciens comptes sans abonnement, seul un administrateur CertCentral peut créer l’ACME Directory URL. Il peut ensuite transmettre les identifiants générés à un compte de service aux droits strictement limités pour l’exploitation courante.
Pour les comptes Enterprise et les autres comptes sans abonnement, l’approbation automatique des demandes de certificat doit être activée ; sans elle, les demandes ACME échouent par défaut.
Les Subscription Accounts n’ont pas besoin de ce paramètre d’approbation automatique des demandes. Les produits disponibles et le statut de l’abonnement doivent néanmoins être appropriés.

Ainsi, les droits étendus nécessaires à la création des identifiants restent séparés du compte d’automatisation utilisé par la suite. Avant la première commande, vérifier en outre l’autorisation d’utiliser le produit, le mode de paiement, ainsi que l’affectation de l’ACME Directory URL et de l’External Account Binding au bon compte et au bon produit. Une personne clairement désignée est responsable de la création, de la rotation et du remplacement d’urgence des identifiants.

Les identifiants ACME doivent être conservés dans un coffre-fort de secrets protégé. Ils ne sont jamais inscrits dans un dépôt, un script shell, un ticket, un exemple de wiki ou un export Postman.

Exemple DigiCert : DCV pour DV, OV et EV

Pour un certificat DV, DigiCert exécute à nouveau la Domain Control Validation à chaque commande ACME ; une DCV antérieure n’est ni prévalidée ni réutilisée. L’hôte d’automatisation doit pouvoir répondre au challenge choisi lors de chaque renouvellement.

Pour les certificats OV et EV, une émission ACME sans intervention requiert une organisation préalablement validée. Le statut du domaine doit également être valide. DigiCert utilise actuellement une validation de domaine OV/EV réutilisable pendant 199 jours ; la validation d’organisation pour les certificats OV publics est actuellement réutilisable pendant 397 jours. Ces deux échéances sont surveillées séparément de l’expiration du certificat.

Pour un certificat wildcard tel que *.example.com, DNS-01 constitue la méthode de validation habituelle. L’accès à l’API DNS ne devrait pouvoir modifier que la zone ou l’enregistrement nécessaire.

Mettre en place un hôte d’automatisation sécurisé

L’hôte d’automatisation traite temporairement la clé privée, les identifiants de la CA et un mot de passe SFOS autorisé à effectuer des écritures. Il doit se trouver dans un environnement de gestion protégé, et non sur le poste d’administration généraliste d’un utilisateur ou dans un environnement d’exécution CI quelconque.

Les exigences minimales sont les suivantes :

système d’exploitation renforcé et à jour, placé sous la responsabilité d’une personne clairement désignée ;
adresse IP source fixe ou réseau de gestion strictement limité ;
accès sortant limité à la CA, à l’API DNS et aux pare-feu prévus ;
identifiants distincts pour la CA, le DNS et chaque pare-feu, ou pour un groupe de pare-feu clairement délimité ;
coffre-fort de secrets plutôt que variables d’environnement, sorties de diagnostic, paramètres de ligne de commande ou fichiers en texte clair ;
droits de fichiers restrictifs et répertoire de travail temporaire sur un stockage chiffré ;
aucune clé privée, aucun mot de passe et aucune requête XML complète dans les journaux ;
ID de commande, pare-feu cible, nom du certificat et résultat traçables, sans contenu secret ;
synchronisation de l’heure et alerte en cas d’échecs répétés ou de durée de validité restante insuffisante.

Si la clé privée est transmise à SFOS sous forme chiffrée, le mot de passe d’importation devrait, pour des raisons de compatibilité, ne pas dépasser 30 caractères. L’aide de l’interface graphique SFOS indique cette limite, tandis que l’aide de l’API décrit, selon le build, une longueur de 4 à 128 caractères. La limitation à 30 caractères vise uniquement la compatibilité et ne constitue pas une recommandation générale sur la longueur des mots de passe. Ce mot de passe aléatoire ne vaut que pour cette clé et est transmis de manière protégée.

Le renforcement de la source, du compte de service, de Device Access et des droits API est décrit dans Sécuriser l’accès à l’API XML de Sophos Firewall. Sous SFOS 22, dans Administration > API access, seul l’IP Host du système d’automatisation est autorisé sous Allowed IP hosts. Dans les versions antérieures, la configuration de l’API se trouve dans un autre chemin de menu.

Test avant le renouvellement en production

Le test utilise un nom non essentiel tel que test-fw.example.com, un objet certificat distinct et un listener dont l’interruption est acceptable. Il est répété après toute mise à jour pertinente de SFOS ou de l’automatisation.

Déterminer le comportement du build utilisé

Les tests permettent de déterminer le comportement du build précis ; ils ne remplacent pas un engagement du fabricant. Les éléments suivants doivent être vérifiés et consignés :

build SFOS exact et API help locale utilisée ;
champs add et update exacts, ainsi que le champ d’identification de l’objet existant ;
résultat d’un nouvel envoi de la même requête et état après l’interruption d’un upload ;
traitement d’un fichier de certificat contenant le certificat leaf et les certificats intermédiaires, ainsi que les objets CA qui en résultent ;
chaîne réellement présentée ;
conservation ou perte des références WebAdmin, portail, WAF et SMTP ;
activation nécessaire du listener ou éventuel redémarrage du service ;
en HA, transfert du certificat, de la clé privée et de l’attribution, ainsi que présentation du certificat après un failover.

Un fichier fullchain ne doit pas être considéré comme pris en charge sans vérification. De même, l’automatisation ne doit présumer ni l’idempotence, ni la conservation des références, ni la sûreté d’une nouvelle tentative automatique après une erreur.

De l’exemple local d’ajout ou de mise à jour à la requête

Voici comment créer une requête concrète pour le build installé, sans prétendre à tort qu’elle est universelle :

Dans l’API help locale du pare-feu cible, accéder à System > Certificates > Certificate > Add Certificate / Update Certificate. Enregistrer l’exemple de configuration et la description des paramètres correspondant précisément à ce build.
Pour le premier cas, utiliser le wrapper add documenté. Pour le second, reprendre l’update qui y figure et son champ d’identification. Ne copier ni l’attribut d’opération ni l’identifiant d’objet depuis un autre build.
Dans l’exemple, remplacer uniquement les valeurs propres à l’environnement : connexion API issue du coffre-fort de secrets, nom d’objet test-public-cert, action d’upload du certificat, format du certificat, nom du fichier de certificat, nom du fichier de clé privée et, le cas échéant, mot de passe d’importation. Supprimer les branches d’exemple inutiles, mais conserver les noms des éléments et leur imbrication.
Générer localement la requête XML résultante sous forme de reqxml éphémère. Les deux noms de fichiers indiqués dans le XML doivent correspondre exactement aux fichiers uploadés.
Dans Postman ou la bibliothèque HTTP utilisée, envoyer une requête POST à l’endpoint suivant et choisir multipart/form-data :
```
https://<Firewall-FQDN>:<Admin-Port>/webconsole/APIController
```
Créer exactement trois parties multipart : la partie fichier indiquée dans l’aide locale pour le certificat, celle qui y est indiquée pour la clé privée et le champ texte reqxml. Les noms des deux premières parties ne doivent pas être devinés ; leur nom actuel et les noms de fichiers sont repris de l’exemple du build cible.
Exécuter d’abord add, puis update avec un nouveau certificat de test. Envoyer également une requête non valide dans l’environnement de test et relire l’état avant toute nouvelle tentative.
La requête n’est validée que lorsque <Response> et <Status> signalent le succès attendu, que seul l’objet prévu a été modifié, qu’aucun objet CA inattendu n’a été créé, que la référence du service réagit comme consigné et que, après l’attribution, le listener externe présente le nouveau certificat avec une chaîne valide. En HA, cela inclut un failover contrôlé.

À partir des résultats, la requête est créée, testée et validée en interne pour ce build précis. Les trois noms de parties, le modèle XML, les valeurs de statut attendues et les conditions d’abandon sont versionnés ensemble, sans enregistrer d’identifiants ni de clés.

Vérifier le certificat avant l’upload

Les exemples suivants utilisent ces valeurs de remplacement :

FQDN du service : vpn.example.com
nom de l’objet SFOS : public-vpn-example-com
certificat leaf : vpn.example.com.pem
clé privée : vpn.example.com.key
bundle intermédiaire : intermediates.pem
bundle de racines de confiance : trust-roots.pem
port HTTPS externe : 443

Lire d’abord les données du certificat :

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

L’émetteur, la période de validité, les SAN et l’empreinte SHA-256 doivent correspondre à la commande. Vérifier ensuite que le certificat et la clé privée appartiennent à la même paire de clés, sans afficher la clé :

(
  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 ne produit aucune sortie si les clés publiques sont identiques. En cas de différence, la procédure est interrompue. Une clé privée chiffrée demande le mot de passe de manière interactive ; dans l’automatisation, celui-ci provient du coffre-fort de secrets et n’apparaît ni dans l’appel du processus ni dans le journal.

La chaîne prévue est vérifiée par rapport au magasin de confiance propre à l’environnement :

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

trust-roots.pem contient les CA racines approuvées dans l’environnement, et intermediates.pem les CA intermédiaires associées à l’émission. La vérification n’est réussie qu’avec la sortie vpn.example.com.pem: OK ; toute autre sortie interrompt l’upload.

Transférer le certificat via l’API XML

Vérifications avant l’upload

Avant toute écriture, comparer le pare-feu cible, le build SFOS, le nom de l’objet et les services à la modification approuvée. Une sauvegarde Sophos Firewall récente, l’accès de gestion alternatif et l’ancien objet certificat doivent être disponibles. Avec le même hôte et le même compte de service, commencer par exécuter une requête de lecture sans danger. Les droits de fichiers et les vérifications locales du certificat ne doivent révéler aucune erreur.

Envoyer la requête et évaluer la réponse

L’automatisation envoie la requête multipart validée pendant le test. Le certificat et la clé privée sont transférés sous forme de fichiers ; reqxml est généré au moment de l’exécution, puis supprimé. Le client utilise le FQDN correspondant au certificat du pare-feu, valide sa CA et s’arrête en cas d’erreur de nom d’hôte ou de certificat. curl -k ou toute désactivation comparable de la vérification TLS est interdite.

Un statut HTTP 200 ou Send successful confirme uniquement le transport. Dans le XML, l’automatisation évalue au minimum l’élément <Response> associé à l’opération et son <Status> en fonction des valeurs validées pendant le test. En cas de timeout, de réponse incomplète ou de statut négatif, elle commence par relire l’état de l’objet ou s’arrête pour permettre une clarification manuelle ; elle ne répète pas la requête d’écriture sans vérification.

Contrôler l’objet et le fichier téléchargé

Sous Certificates > Certificates, rechercher l’objet cible. Vérifier dans l’interface les informations qui y sont effectivement proposées, notamment le nom de l’objet, l’état de la clé privée, Trusted, les valeurs Subject, Issuer et Purpose visibles au survol, ainsi que tout objet certificat ou CA supplémentaire inattendu.

Il ne faut pas présumer que le numéro de série, les SAN, la date d’expiration et l’empreinte SHA-256 sont des champs garantis dans l’interface. Exporter le certificat cible depuis SFOS au moyen de l’action de téléchargement, puis vérifier le fichier téléchargé :

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

Ces valeurs doivent correspondre au fichier vérifié avant l’upload. À lui seul, l’état vert Trusted ne prouve ni que le certificat est attribué au bon service, ni que la chaîne présentée par le listener est complète. Les formats, la chaîne et l’importation dans l’interface sont expliqués dans Importer et attribuer des certificats sur Sophos Firewall.

Attribuer le certificat au service

L’importation et l’attribution sont deux modifications distinctes. Un nouvel objet doit être explicitement attribué au service souhaité. Lors d’une mise à jour, utiliser la méthode confirmée pendant le test, puis contrôler la conservation effective des références après l’exécution.

WebAdmin et portails

Sous Administration > Admin and user settings > Admin console and end-user interaction, le champ Certificate s’applique conjointement à WebAdmin Console, User Portal, VPN Portal, Captive Portal, ainsi qu’à SPX Registration et Reply Portal. Le certificat doit contenir dans ses SAN tous les noms réellement utilisés. Après Apply, vérifier chaque FQDN et chaque port séparément ; maintenir ouverte une session d’administration existante ainsi qu’une autre voie de gestion locale.

WAF

Pour une publication WAF, le certificat est sélectionné dans la règle concernée, sous Rules and policies > Firewall, dans le champ HTTPS certificate. Le domaine, le SNI, le Listen Port et le SAN doivent correspondre. Lors de l’enregistrement, les règles Web Server Protection redémarrent ; des connexions existantes peuvent être interrompues. Il faut vérifier pendant le test, avec le build utilisé, si le remplacement d’un certificat déjà référencé déclenche lui aussi un rechargement.

SMTP TLS

En mode MTA, la sélection se trouve sous Email > General settings > SMTP TLS configuration, dans le champ TLS certificate. Après Apply, tester séparément STARTTLS et, le cas échéant, TLS implicite. Le VPN et d’autres utilisations de certificats peuvent posséder leurs propres attributions ; un nom identique ne signifie pas qu’elles basculent automatiquement.

Valider depuis l’extérieur avec SNI et le bon port

Commencer par contrôler la chaîne et le nom d’hôte depuis un hôte de test externe représentatif :

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

Les certificats intermédiaires nécessaires et Verification: OK sont attendus. -servername envoie le SNI ; remplacer le FQDN et le port par ceux du service réel.

L’empreinte, le numéro de série et les autres données du certificat leaf peuvent être lus lors d’une seconde étape exécutable utilisant la même configuration de listener :

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

Le numéro de série, l’empreinte SHA-256, la période de validité, l’Issuer et les SAN doivent correspondre au certificat approuvé. Tester ensuite l’application elle-même, par exemple la connexion au portail, le healthcheck WAF ou une autre fonction de bout en bout sans danger. Un load balancer, un CDN ou un reverse proxy placé en amont peut terminer TLS avec un autre certificat ; le point de test doit donc correspondre à la fonction SFOS visée.

SMTP avec STARTTLS nécessite un appel distinct :

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

Pour TLS implicite sur le port 465, omettre -starttls smtp. Ici aussi, la chaîne et le nom d’hôte sont confirmés par Verification: OK ; les données du certificat leaf peuvent être lues avec la méthode d’extraction précédente et des options de connexion adaptées. Tester ensuite le flux de messagerie réel.

Fenêtre de maintenance, rollback et HA

Préparer la fenêtre de maintenance

La première exécution en production ainsi que toute modification de la requête, du build SFOS, du produit de la CA ou de la composition de la chaîne s’effectuent dans une fenêtre de maintenance. L’ancien objet reste disponible ; les attributions concernées, l’accès de gestion alternatif et les responsables de la procédure de retour arrière et du contrôle externe sont connus.

Choisir une stratégie de rollback

Pour un nouvel objet, le retour arrière le plus clair consiste à sélectionner à nouveau l’ancien certificat dans le service concerné, puis à retester le listener depuis l’extérieur. L’ancien objet n’est donc pas supprimé pendant la même exécution.

Lors de la mise à jour d’un objet existant, seule la méthode de retour arrière confirmée pendant le test doit être utilisée. Si la réimportation sûre du contenu précédent n’a pas été démontrée, créer de manière prudente un nouvel objet distinct, puis l’attribuer explicitement.

Tester HA séparément

Dans un cluster HA, SFOS synchronise en principe la configuration du Primary vers l’Auxiliary. Le certificat, la clé privée et l’attribution au service doivent néanmoins être vérifiés sur les deux nœuds ou sur le service commun. Procéder ensuite à un failover contrôlé et vérifier le listener depuis l’extérieur. La procédure n’est validée pour HA qu’après la réussite de ce test.

Surveillance et fonctionnement récurrent

L’automatisation doit signaler suffisamment tôt les erreurs et les renouvellements manquants. Les éléments suivants sont surveillés en permanence :

nombre de jours restants du certificat présenté par le listener externe et prochaine fenêtre de renouvellement de la CA ;
état DCV et, pour OV/EV, validation d’organisation également ;
dernière commande réussie auprès de la CA et dernier upload SFOS réussi ;
empreinte attendue et empreinte réellement présentée ;
erreurs API, réponses ambiguës et exécutions interrompues ;
nouveaux objets certificat ou CA non planifiés ;
expiration et rotation des identifiants ;
en HA, dernier test de failover réussi.

L’alerte doit laisser suffisamment de temps pour la durée du traitement par la CA et de la DCV, la réaction interne, la fenêtre de maintenance et le retour arrière. Après une transition réussie, l’ancien certificat est conservé pendant la période d’observation définie. Les fichiers temporaires de certificat, de clé et XML sont supprimés de manière contrôlée ; les données de preuve conservées durablement ne contiennent que des métadonnées non secrètes.

Résolution des problèmes par symptôme

La CA n’émet pas de nouveau certificat

Vérifier auprès du fournisseur concerné l’autorisation d’utiliser le produit, le statut du compte, le mode de paiement et la DCV. Dans l’exemple DigiCert, contrôler également l’automatisation ainsi que l’approbation automatique des demandes propre au modèle de compte. Pour OV/EV, l’organisation et le domaine doivent être valides. En cas d’erreur DNS-01, vérifier le DNS public faisant autorité, et pas seulement le résolveur local.

L’API XML n’est pas accessible

Vérifier l’adresse IP source telle qu’elle est vue par le pare-feu, Allowed IP hosts, Device Access, le routage, le port d’administration et le certificat du pare-feu. Le test doit être effectué depuis l’hôte d’automatisation réel.

La requête HTTP aboutit, mais le certificat n’est pas mis à jour

Vérifier <Response> et <Status>, et pas uniquement le code HTTP. Comparer ensuite le nom de l’objet, le format du fichier, la longueur de mot de passe autorisée et les champs propres au build avec l’aide API locale. Sous Diagnostics > Troubleshooting logs, apiparser.log, validation.log et validationError.log peuvent aider ; supprimer tous les identifiants avant de les partager. Si l’état est incertain, commencer par télécharger et vérifier l’objet certificat au lieu de répéter la requête d’écriture sans contrôle.

L’objet est nouveau, mais le service présente encore l’ancien certificat

Vérifier l’attribution au service, la règle WAF, la sélection commune du certificat pour WebAdmin et les portails, ou la configuration SMTP. Tester ensuite avec SNI sur le bon port et exclure la présence d’un endpoint TLS en amont.

Le certificat n’est pas `Trusted` ou la chaîne est incomplète

Comparer l’Issuer du certificat leaf avec les CA intermédiaires installées. Utiliser la méthode d’importation confirmée pendant le test et contrôler avec -showcerts la chaîne envoyée par le listener.

Après une mise à jour ou un failover, l’ancien certificat réapparaît

Déterminer quel nœud et quel listener répondent. Comparer ensuite l’empreinte de l’objet téléchargé, la référence du service et l’état HA. En cas d’écart, exécuter la procédure de retour arrière confirmée et arrêter l’automatisation.

Checklist de validation

Le renouvellement en production n’est validé que si tous les points suivants sont remplis :

L’autorisation de la CA, le paiement, la DCV et, le cas échéant, la validation d’organisation sont valides.
Le build, l’aide API locale et la requête multipart correspondent au test réussi.
Les vérifications locales du certificat, de la clé et de la chaîne ont réussi.
<Response> et <Status> signalent le succès attendu ; seul l’objet cible a été modifié.
Le fichier de l’objet téléchargé présente le numéro de série, les SAN, la période de validité et l’empreinte SHA-256 attendus ; la clé privée et l’état Trusted sont corrects, et aucun objet inattendu n’a été créé.
Avec SNI, chaque FQDN et chaque port réels présentent le nouveau certificat, la chaîne attendue et Verification: OK ; le service associé fonctionne.
En HA, le failover contrôlé et la vérification externe ont réussi.
La surveillance détecte la nouvelle date d’expiration et le résultat positif ; l’ancien certificat reste disponible comme solution de retour arrière jusqu’à la fin de la période d’observation.