Certificats SSL

Opfield prend en charge les certificats ACME, les certificats téléversés et les certificats liés depuis la PKI interne. ACME peut utiliser HTTP-01 ou DNS-01. Le matériel téléversé doit inclure la chaîne complète et la clé privée correspondante.

Donnez à chaque Route publique un certificat avec un responsable connu, une méthode de renouvellement et un chemin de remplacement testé. Opfield émet et renouvelle les certificats ACME et de PKI interne, suit les Routes qui utilisent chaque certificat et les distribue aux nœuds Ingress qui en ont besoin. Le contrôle des domaines, le DNS externe, l’approbation des noms des certificats et la réponse à une clé compromise restent de votre ressort.

Choisissez l’automatisation lorsqu’Opfield peut prouver de manière fiable le contrôle du domaine. Choisissez le téléversement lorsqu’une autorité de certification externe ou un processus d’entreprise détient l’émission. Dans les deux cas, le succès signifie qu’un client externe valide le nom d’hôte et la chaîne attendus sur chaque Route concernée ; un certificat marqué Active mais non rattaché et non servi n’est pas un déploiement terminé.

Rattachez les certificats aux Routes plutôt que de copier manuellement des fichiers sur les hôtes nginx. Opfield ne distribue des réplicas locaux aux nœuds que là où des Routes TLS activées les utilisent. Surveillez l’expiration et l’état du renouvellement, et testez le renouvellement avant que la durée de vie restante ne devienne une urgence opérationnelle.

Pour les échecs HTTP-01, vérifiez le placement du domaine, le port 80 public, le DNS et le routage du défi. Pour les certificats téléversés, vérifiez la couverture des noms d’hôte, l’ordre de la chaîne, la correspondance de la clé et l’encodage pris en charge.

Choisir le chemin du certificat

• Utilisez HTTP-01 lorsque le nom d’hôte se résout déjà vers le nœud Ingress attribué et que le port 80 public est joignable.
• Utilisez DNS-01 lorsque des noms wildcard sont nécessaires ou que la validation HTTP n’est pas pratique. Configurez un connecteur DNS pris en charge avec le plus petit périmètre de zone possible.
• Utilisez Upload pour les certificats émis hors d’Opfield. Téléversez la clé privée, le certificat feuille et les intermédiaires requis comme une seule chaîne cohérente.
• Utilisez Internal CA pour lier un certificat émis par la PKI interne d’Opfield, pour des services dont les clients font confiance à votre CA privée.

Avant l’émission, vérifiez que le domaine existe, que son placement est définitif et que les noms demandés correspondent exactement aux Routes prévues. L’émission d’un certificat ne répare pas un DNS ou un placement de Route incorrects.

Décisions de responsabilité et de risque

Désignez un responsable des échecs de renouvellement et une fenêtre d’escalade plus courte que la durée de vie restante du certificat. Examinez attentivement les demandes de wildcard : elles réduisent les répétitions opérationnelles, mais étendent l’impact de la compromission d’une clé privée. N’accordez aux connecteurs DNS que les permissions de zone nécessaires aux enregistrements de défi, et gardez les clés privées téléversées hors des tickets, des discussions, des dépôts et des notes locales des opérateurs.

Avant de modifier un certificat partagé par plusieurs Routes, examinez chaque relation de déploiement affichée par Opfield. Décidez si le changement est un renouvellement de routine, une migration planifiée d’autorité ou une rotation de clé d’urgence ; chacun a des exigences différentes de communication et de retour arrière.

Émettre et rattacher

1. Ouvrez Certificates (l’onglet SSL) et choisissez Add Certificate.
2. Sélectionnez Let’s Encrypt, Upload ou Internal CA et fournissez les noms et le matériel requis.
3. Attendez la fin de la validation et de l’émission.
4. Ouvrez chaque Route dépendante et sélectionnez le certificat.
5. Activez TLS et appliquez la Route.
6. Attendez la distribution vers le nœud Ingress attribué.
7. Vérifiez depuis un client externe la chaîne publique, le nom d’hôte, le protocole et l’expiration.

Opfield ne distribue le matériel de clé privée qu’aux nœuds qui en ont actuellement besoin. Ne copiez pas de fichiers de certificats gérés entre hôtes nginx ; les copies manuelles échappent au suivi des relations, à la rotation et au nettoyage.

Renouvellement et rotation

Surveillez la durée de vie restante et la dernière tentative de renouvellement. Testez les identifiants des connecteurs DNS et la joignabilité des défis HTTP avant que l’expiration ne devienne urgente. Pour le matériel téléversé, créez ou mettez à jour le certificat géré via Opfield et vérifiez chaque Route rattachée après le remplacement.

Modifier un certificat peut affecter plusieurs Routes. Examinez les relations avant la rotation, conservez le matériel précédent jusqu’à la réussite de la vérification externe, et évitez de combiner le remplacement d’un certificat avec des changements d’ingress sans rapport.

Les critères de réussite d’un renouvellement sont : la nouvelle fenêtre de validité est visible, Opfield signale une distribution réussie vers chaque nœud Ingress requis, les clients publics reçoivent la nouvelle chaîne, et aucune Route ne se rabat sur un certificat par défaut ou obsolète. Ne conservez le certificat précédent que le temps exigé par la politique et par un éventuel retour arrière d’incident ; ne laissez pas du matériel de clé privée expiré largement accessible.

Certificats de PKI interne

Un certificat de PKI interne lié est réémis automatiquement, avec une vérification quotidienne, lorsque les deux tiers de sa durée de vie sont écoulés ou qu’il reste 30 jours ou moins. Le nouveau certificat provient de la même CA et du même modèle, avec le même sujet, les mêmes noms, le même algorithme de clé et la même durée de vie — en se terminant avec la CA si nécessaire —, et Opfield le distribue à chaque Route qui l’utilise. Cela couvre aussi les certificats référencés directement par une Route.

• La réémission automatique ne fonctionne que lorsqu’Opfield détient la clé privée. Lier un tel certificat l’active ; les certificats signés à partir d’une CSR ne sont jamais réémis, et leur alerte d’expiration l’indique.
• Le certificat précédent n’est pas révoqué, car une copie exportée peut encore être utilisée ; son alerte d’expiration signale qu’un certificat plus récent existe.
• La colonne Auto-Renew affiche Reissue pour les certificats dotés de la réémission automatique. Renew dans le menu de ligne réémet immédiatement ; cela nécessite ssl:cert:issue sur le certificat SSL et pki:cert:issue sur la CA. Disable Auto-Renew désactive la réémission automatique, et le certificat conserve alors son matériel actuel ; Enable Automatic Reissue la réactive.
• Une réémission en échec est affichée sur le certificat et déclenche une alerte par jour.

Détails pour l’opérateur : gestion des échecs

• Délai dépassé pour HTTP-01 : vérifiez le DNS public, le port 80, le placement du domaine et le routage du défi.
• Échec de DNS-01 : vérifiez l’autorisation du connecteur, la sélection du compte et de la zone, la propagation et les enregistrements de défi obsolètes.
• Clé non correspondante : confirmez que la clé privée téléversée correspond au certificat feuille.
• Chaîne incomplète : incluez les intermédiaires dans l’ordre des émetteurs et excluez les racines sans rapport.
• Non distribué : confirmez qu’une Route TLS activée sur ce nœud référence bien le certificat.

Ne supprimez un certificat qu’une fois toutes les Routes détachées et un remplaçant vérifié de l’extérieur. Opfield refuse de supprimer un certificat encore utilisé par une Route ou par le profil wildcard de Pages, avec 409 CERT_IN_USE, même lorsqu’une Route y est rattachée pendant la suppression. Conservez le matériel exporté conformément à la politique de conservation des clés de l’organisation.

Si une clé est susceptible d’avoir été compromise, traitez le remplacement comme un incident plutôt que comme un renouvellement ordinaire. Émettez une nouvelle paire de clés, mettez à jour toutes les Routes dépendantes, vérifiez de l’extérieur, révoquez l’ancien certificat lorsque l’autorité prend en charge la révocation, et consignez les noms concernés et la fenêtre d’exposition. Un retour arrière ne doit jamais restaurer un certificat dont la clé privée est soupçonnée d’être compromise.