Déploiement
Poussez les certificats directement là où ils terminent le TLS — avec validation et rollback.
Vue d'ensemble
Plutôt que d'exporter un certificat et de l'installer manuellement, DuoKey peut le déployer directement sur l'équipement ou le service qui termine le TLS. Chaque déploiement s'exécute comme une tâche qui valide le résultat et peut faire l'objet d'un rollback.
| Cible | Notes du connecteur |
|---|---|
| F5 BIG-IP | iControl REST — déploie le certificat+clé ou le certificat seul ; découverte, test et rollback |
| Fortinet FortiGate | Déploiement et rollback |
| Azure App Service | Lie les certificats aux app services |
| Entra ID | App Proxy et App Registration |
| Microsoft IIS · Active Directory / LDAPS · Windows CAPI | Orchestré par agent (PowerShell) — un agent scanner lié à la cible exécute l'import/la liaison en local ou via WinRM |
| Nginx · Java Keystore | SSH — Cockpit se connecte directement, dépose le certificat/la clé (ou l'importe dans le keystore) et exécute la commande de reload/restart |
| Apache HTTPD | Configuration uniquement pour l'instant — la création de cible est possible, le déploiement effectif n'est pas encore câblé |
| ServiceNow CMDB | Synchronisation d'inventaire / d'expiration (pas une cible de terminaison TLS) |
Cycle de vie d'une tâche de déploiement
| État | Signification |
|---|---|
| pending | Tâche créée, pas encore démarrée |
| running | Envoi du certificat vers la cible en cours |
| validating | Confirmation que la cible sert désormais le nouveau certificat |
| succeeded / failed | Résultat final |
| rolled_back | Annulée après achèvement |
Le rollback est la seule transition autorisée après l'achèvement d'une tâche, de sorte qu'un déploiement défectueux puisse être ramené au certificat précédent. F5 et Fortinet disposent de points de terminaison de rollback dédiés ; les cibles génériques passent par l'API des tâches de déploiement.
Opérations des connecteurs
Tous les connecteurs partagent un ensemble uniforme d'opérations — découverte / inventaire / ajout / suppression / ré-enrôlement — afin que la gestion des certificats sur des cibles hétérogènes reste cohérente. Des profils de connexion réutilisables stockent une seule fois les identifiants de la cible et peuvent être testés et réassociés.
F5 BIG-IP
Enregistrer la cible F5
Ajoutez la cible F5 (adresse de gestion + identifiants) et exécutez un test pour confirmer la connectivité.
Déployer
Déployez le certificat et la clé, ou le certificat seul lorsque la clé est déjà présente. La tâche valide la liaison du profil SSL.
Revenir en arrière si nécessaire
Si la validation échoue ou que le changement se comporte mal, effectuez un rollback de la tâche vers le certificat précédent.
Microsoft IIS, Active Directory / LDAPS & Windows CAPI (agent)
Ces trois cibles partagent le même modèle d'exécution — un pattern à la Keyfactor Universal Orchestrator. Un agent scanner sur site s'enregistre auprès de Cockpit et est lié à la cible ; au lieu que Cockpit s'y connecte directement, l'agent récupère les tâches de déploiement à son propre rythme de heartbeat et les exécute en local (ou via WinRM contre un hôte distant).
Enrôler et lancer l'agent
Sur l'hôte Windows (ou la machine qui fera du WinRM vers celui-ci), enrôlez-vous une fois avec un jeton d'installation à usage unique généré depuis Scanner Agents → Generate installer dans l'interface Cockpit :
dke-scanner-agent enroll --server https://<hote-cockpit> --token <jeton-enrolement>Cette commande écrit l'identité de l'agent et sa clé API dans ~/.dke/agent.toml (mode 0600). Démarrez ensuite le processus persistant de l'agent, qui se connecte à Cockpit, envoie des heartbeats et interroge les tâches de déploiement :
dke-scanner-agent agentAucun flag séparé n'est nécessaire pour activer les tâches de déploiement — chaque agent enrôlé annonce automatiquement la capacité cert_deploy, il apparaît donc dans le sélecteur d'agent de l'assistant dès qu'il est enrôlé et lancé. Le processus doit continuer à tourner (comme un service Windows, pas une session interactive qui se termine à la déconnexion) pour que les tâches soient récupérées ; voir Mode Agent pour la référence CLI complète, dont --heartbeat-interval et --config.
Lier la cible à l'agent
Dans l'assistant de déploiement, choisissez l'agent enrôlé pour la cible — ou, pour un hôte distant sur lequel l'agent ne tourne pas directement, choisissez le transport WinRM et fournissez le nom d'utilisateur, le mot de passe, le port et les réglages TLS de l'hôte distant.
Enregistrer la cible
Microsoft IIS : nom du site, hôte de liaison et port, magasin machine (LocalMachine\My ou WebHosting), SNI. Active Directory / LDAPS : le magasin dédié NTDS\My du DC, le FQDN du contrôleur de domaine, rechargement LDAPS en place (sans redémarrage). Windows CAPI : l'IP/port de liaison SSL et le GUID d'application requis par netsh http add sslcert.
Déployer
Cockpit résout le certificat géré, construit un PFX et met en file une tâche chiffrée. L'agent la récupère, importe le certificat dans le magasin de certificats Windows et le lie — une liaison de site IIS, un rechargement LDAPS, ou une liaison netsh http add sslcert — puis renvoie le résultat, ce qui met à jour la tâche de déploiement.
Importer dans le magasin de certificats machine et lier IIS ou CAPI nécessite un contexte PowerShell élevé (l'agent exécute powershell.exe pour lancer Import-Module WebAdministration, Import-PfxCertificate -CertStoreLocation Cert:\LocalMachine\My, et netsh http add sslcert). Installez dke-scanner-agent agent comme service Windows tournant sous LocalSystem ou un compte de service administratif — une session console interactive non-admin échouera sur ces étapes avec une erreur d'accès refusé, même si l'agent lui-même démarre et envoie ses heartbeats correctement.
Nginx & Java Keystore (SSH)
Cockpit atteint ces deux cibles directement en SSH — aucun agent requis.
Enregistrer la cible
Hôte SSH, port et nom d'utilisateur, plus soit un mot de passe soit une clé privée (PEM, optionnellement protégée par une passphrase) — avec une empreinte SHA-256 de clé d'hôte optionnelle à épingler. Nginx prend aussi les chemins des fichiers certificat/clé et une commande de reload. Java Keystore prend le chemin du keystore, l'alias, le type de keystore (PKCS12 ou JKS historique), le mot de passe du keystore et une commande de restart optionnelle.
Tester la connexion
Confirme que les identifiants SSH fonctionnent et rapporte ce qui est déjà déployé — une lecture openssl x509 du fichier certificat pour Nginx, une vérification de présence du fichier keystore pour Java Keystore.
Déployer
Nginx : Cockpit écrit le certificat et la clé privée aux chemins configurés via SSH, puis exécute la commande de reload. Java Keystore : Cockpit construit un PKCS#12 en local à partir du certificat géré, l'envoie à l'hôte via SSH et l'importe avec keytool -importkeystore sous l'alias configuré, puis exécute la commande de restart optionnelle.
Laisser l'empreinte de clé d'hôte vide fait confiance à la clé présentée par l'hôte lors de la première connexion. Épinglez l'empreinte SHA-256 sur la cible pour la production.
Référence API
La gestion des cibles de déploiement, l'exécution et le rollback des tâches de déploiement, le stockage de profils de connexion réutilisables, et la synchronisation d'inventaire vers ServiceNow CMDB sont tous disponibles par programmation via l'API de la plateforme.