Renouvellement automatique et alertes d'expiration
Renouvelez les certificats déployés et poussez le remplaçant sans intervention, et prévenez vos équipes avant toute expiration.
Politiques de renouvellement et de redéploiement
Une politique de renouvellement est liée à une cible de déploiement : un F5 BIG-IP, un FortiGate, un hôte Windows IIS ou Active Directory LDAPS géré par l'agent, ou une autre cible des connecteurs de déploiement. Une fois un certificat déployé sur cette cible, Cockpit le renouvelle avant son expiration et pousse le remplaçant par le même connecteur.
Ce qui se passe chaque heure
Trouver le certificat déployé
Le dernier déploiement réussi sur la cible donne le certificat qu'elle sert et la configuration utilisée pour le pousser. Si rien n'a encore été déployé, la politique attend.
Décider s'il est à renouveler
Le certificat est à renouveler lorsqu'il expire dans le seuil de la politique (1 à 365 jours). Le seuil est plafonné à la moitié de la durée de vie du certificat : un seuil de 30 jours sur un certificat de 47 jours vaut 23,5 jours, sur un certificat de 7 jours 3,5 jours, si bien qu'un remplaçant à courte durée de vie n'est jamais immédiatement à renouveler. Les certificats révoqués ne sont jamais renouvelés ; les certificats expirés encore déployés le sont.
Attendre les déploiements en cours
Si un déploiement vers la cible est encore en cours (par exemple un agent Windows ne l'a pas encore récupéré), le renouvellement attend au lieu d'émettre un autre certificat.
Émettre le remplaçant
La CA de la politique émet un certificat avec le même sujet, les mêmes SAN, la même durée de validité et le même type de clé (ou l'algorithme défini dans la politique).
Redéployer
Le remplaçant est poussé par le chemin d'origine : le connecteur F5 ou FortiGate, une nouvelle tâche d'agent pour les cibles Windows, ou le connecteur générique.
Journaliser et alerter
Un succès est enregistré dans le journal d'activité et le journal d'audit (avec le certificat remplacé). Un échec est enregistré avec son erreur et retenté après 1 heure, puis 2, 4… jusqu'à 24 heures. Après le nombre maximal de tentatives de la politique (1 à 10), la politique est suspendue pour intervention manuelle et une alerte « renouvellement à traiter » part vers les canaux d'alerte du tenant (et vers ServiceNow sous forme d'incident lorsque ce connecteur est configuré). Enregistrer à nouveau la politique la relance.
Plusieurs réplicas de Cockpit peuvent exécuter la même planification : chaque tentative est réservée de façon atomique, un certificat n'est donc renouvelé qu'une fois.
Configurer une politique
Dans PKI > Déploiement, cliquez sur le badge de renouvellement automatique d'une cible. La boîte de dialogue affiche le certificat déployé, la date à laquelle son renouvellement devient dû, si le seuil a été plafonné, si un déploiement est en cours et, après des échecs, quand la prochaine tentative peut avoir lieu.
| Champ | Plage | Signification |
|---|---|---|
| Activée | oui / non | Une politique désactivée est conservée mais ignorée |
| Seuil de renouvellement (jours) | 1 à 365 | Renouveler lorsque le certificat expire dans ce nombre de jours (plafonné à la moitié de sa durée de vie) |
| Tentatives max. | 1 à 10 | Échecs avant suspension de la politique |
| CA émettrice | une CA du tenant | CA qui signe le remplaçant |
| Type de clé du remplaçant | identique, ECDSA P-256 / P-384 / secp256k1, RSA-2048 / 4096 | Algorithme de clé du remplaçant |
Retour arrière
Un renouvellement est une tâche de déploiement ordinaire : il peut être annulé depuis PKI > Déploiement > Tâches de déploiement comme un déploiement manuel (permission Operations.Pki.Deploy.Rollback) : F5 réassocie le certificat précédent, FortiGate restaure l'association précédente et les cibles Windows reçoivent une tâche d'agent qui retire le certificat déployé. Si l'ancien certificat est toujours à renouveler, l'exécution suivante le renouvelle à nouveau : désactivez d'abord la politique.
Limites
- Seuls les certificats émis par une CA Cockpit avec une clé gérée par la plateforme sont renouvelés (le déploiement a besoin de la clé privée). Les certificats d'émetteurs externes et ceux obtenus via ACME sont renouvelés par leur client ou leur émetteur, pas par ce mécanisme.
- Le certificat remplacé n'est ni retiré de la cible ni révoqué.
- Les certificats post-quantiques et composites ne sont pas renouvelés par les politiques.
- L'historique des renouvellements figure dans les journaux d'activité et d'audit, pas dans un panneau dédié.
API
| Méthode et chemin | Permission |
|---|---|
GET /api/pki/deploy/renewal-policies | Operations.Pki.Deploy.Read |
GET /api/pki/deploy/targets/{id}/renewal-policy | Operations.Pki.Deploy.Read |
PUT /api/pki/deploy/targets/{id}/renewal-policy | Operations.Pki.Deploy.ConfigureTarget |
DELETE /api/pki/deploy/targets/{id}/renewal-policy | Operations.Pki.Deploy.ConfigureTarget |
GET .../renewal-policy renvoie la politique et un aperçu du certificat déployé (expiration, seuil effectif, date d'échéance, déploiement en cours, prochaine tentative).
Alertes d'expiration
Chaque tenant peut prévenir ses équipes avant l'expiration des certificats, par e-mail et via ses webhooks (Microsoft Teams, Slack, Rocket.Chat ou un point de terminaison JSON générique). Les alertes sont désactivées tant qu'un administrateur du tenant ne les active pas dans PKI > Alertes.
Ce qui est surveillé
- Certificats émis : tout certificat actif et non révoqué émis par les CA du tenant.
- Certificats découverts (optionnel, activé par défaut) : certificats trouvés par les scanners réseau et les agents, suivis par empreinte, si bien qu'un certificat vu sur de nombreux hôtes ou dans de nombreux scans n'alerte qu'une fois.
Les certificats déjà expirés figurent dans les tableaux de bord, sans alerte.
Seuils
Les seuils sont exprimés en jours avant expiration, par défaut 30, 14, 7, 1 (jusqu'à 8 valeurs entre 1 et 365). Le contrôle s'exécute chaque heure. Chaque certificat est alerté une fois par seuil, au seuil le plus serré déjà franchi : un certificat découvert 5 jours avant expiration alerte une fois (seuil de 7 jours), pas aussi pour 30 et 14. Un certificat renouvelé a une nouvelle date d'expiration, ses propres seuils alertent donc à nouveau. Un redémarrage, une réexécution ou plusieurs réplicas ne renvoient jamais une alerte.
Canaux
| Canal | Fonctionnement |
|---|---|
| Un récapitulatif par exécution pour jusqu'à 20 destinataires (jusqu'à 200 certificats listés, le reste compté). Envoyé via le relais SMTP propre au tenant ; à défaut, le relais de la plateforme ne livre qu'aux utilisateurs du tenant | |
| Microsoft Teams, Slack, Rocket.Chat, webhook générique | Événement cert.expiry_warning, livré à chaque webhook du tenant abonné à « Certificat bientôt expiré » (Administration > Webhooks). Teams et Slack reçoivent une carte ; les webhooks génériques reçoivent du JSON, signé HMAC lorsqu'un secret est défini |
| Échecs de renouvellement | Lorsqu'une politique de renouvellement est suspendue, les mêmes destinataires et webhooks reçoivent une alerte « renouvellement à traiter » (événement cert.renewal_failed) |
Jusqu'à 25 événements webhook par certificat sont envoyés par exécution, le reste dans un événement récapitulatif. Un événement par certificat contient :
{
"title": "Certificate expires in 6 day(s): www.example.com",
"common_name": "www.example.com",
"source": "issued",
"certificate_id": "…",
"serial_number": "…",
"host": null,
"not_after": "2026-10-21T10:00:00+00:00",
"days_remaining": 6,
"threshold_days": 7
}Les adresses des webhooks sont contrôlées contre les cibles privées, de bouclage, link-local et de métadonnées cloud à l'enregistrement puis avant chaque livraison (les installations sur site peuvent autoriser explicitement des cibles internes). Les webhooks Teams et Slack doivent utiliser HTTPS, les redirections ne sont pas suivies, et les adresses et secrets des webhooks ne sont jamais journalisés. Chaque tentative de livraison apparaît dans l'historique du webhook.
Paramètres et permissions
La consultation nécessite Operations.Pki.ExpiryAlerts.Read ; la modification des paramètres ou l'envoi d'une alerte de test nécessite Operations.Pki.ExpiryAlerts.Configure. Les deux sont accordées au rôle Admin et peuvent être données à d'autres rôles.
{
"is_enabled": true,
"thresholds_days": [30, 14, 7, 1],
"email_enabled": true,
"email_recipients": ["[email protected]"],
"webhook_enabled": true,
"include_discovered": true
}| Méthode et chemin | Rôle |
|---|---|
GET / PUT /api/pki/expiry-alerts/settings | Lire / modifier les paramètres |
POST /api/pki/expiry-alerts/test | Envoyer une alerte de test |
GET /api/pki/expiry-alerts/history | Les 100 alertes les plus récentes |
Limites
- Les destinataires sont définis par tenant, pas par propriétaire de certificat ni par CA.
- Jusqu'à 5 000 certificats par source sont examinés par exécution, par ordre d'expiration.
- Un événement webhook publié juste avant un redémarrage peut être perdu (l'alerte reste enregistrée comme envoyée).
- Les certificats émis via ACME ne sont pas encore couverts (voir Certificats à courte durée de vie).