# Certificats TLS dans Webship : le CA ACME intégré
Un certificat TLS accomplit deux tâches : il aide à chiffrer une connexion et indique au client quelle identité il est en train de contacter. Le chiffrement peut être fort tandis que la décision de confiance est incorrecte pour le public. C’est pourquoi l’automatisation des certificats doit commencer par une question : qui doit faire confiance à ce site ?
Webship 1.4.0 fait ce choix de manière indépendante pour chaque site configuré. Un site web public peut utiliser un certificat ACME approuvé par le navigateur, un service interne peut utiliser l’autorité de certification privée intégrée de Webship, et un site disposant d’une PKI existante peut conserver des fichiers de certificats gérés par l’opérateur. Ils peuvent tous partager un processus Webship sans partager une clé privée ou une limite de confiance.
Quatre modes de certificat automatique, sélectionnés par site
Le champ certificate_mode appartient à chaque entrée [[sites]]. Ce n'est pas un interrupteur global.
| Mode | Source de confiance | Meilleure correspondance | Chemin de validation | | --- | --- | --- | --- | | par_site | Magasins de confiance des navigateurs publics et des systèmes d'exploitation | Un site public avec un nom d'hôte exact | ACME public avec TLS-ALPN-01 | | flotte | Navigateurs publics et magasins de confiance des systèmes d'exploitation | Grands ensembles de noms de troisième et quatrième niveau sous des domaines enregistrés explicitement | ACME public avec DNS-01 et fragments de certificats stables | | intégré | Une racine Webship privée installée par l'opérateur | Services internes, appareils gérés, flottes privées et environnements de test | Délivrance en cours de processus ; aucun défi externe | | partagé | Magasins de confiance publics des navigateurs et des systèmes d'exploitation | Déploiements hérités utilisant intentionnellement un groupe multi-SAN public | ACME public avec TLS-ALPN-01 |
Par défaut, c'est par_site. Il commande un certificat public pour le nom exact du site. Le mode Fleet est l'option publique évolutive pour de nombreux sous-domaines profonds. Le mode intégré utilise l'autorité de certification privée en processus de Webship. Le mode partagé reste disponible pour la compatibilité, mais ce n'est pas le mode par défaut.
Un certificat complet et une clé sous [sites.tls] ont toujours la priorité sur l'émission automatique pour ce site.
Que signifie « ACME CA intégré »
La section de configuration est nommée [acme_ca], mais la CA intégrée n'est pas un service ACME public ou accessible par le réseau. Elle n'expose aucun point de terminaison de répertoire, n'accepte aucune inscription à distance, n'appelle aucune API de registraire et ne réalise aucun défi de preuve de contrôle.
Au lieu de cela, Webship conserve tout le chemin d'émission privé dans un seul processus :
- Le site sélectionne certificate_mode = "embedded".
- Webship charge ou crée l'identité racine privée dans le répertoire d'état configuré.
- Webship génère une nouvelle clé privée pour le site.
- La racine intégrée signe un certificat de feuille pour ce nom exact.
- Webship valide l'identité complétée avant de l'installer dans le résolveur TLS en direct.
- Le certificat est ensuite disponible pour chaque protocole activé pour ce site.
Un défi réseau de style ACME ne prouverait Webship qu'à lui-même, donc le chemin intégré n'a délibérément aucun protocole réseau. La section [acme_ca] est un état de PKI privé : elle définit où se trouve la racine et combien de temps les certificats leaf émis restent valides.
Configurer un certificat intégré pour un site
Ceci est la forme minimale pour un site privé :
~~~toml écouter = "0.0.0.0:443"
[tls] unknown_sni = "reject"
[tls_automatique] activé = vrai cache_dir = "/var/lib/webship/acme"
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[sites]] domaine = "service.internal.example" root = "/srv/service" certificate_mode = "intégré"
[sites.protocoles] h1 = vrai h2 = vrai h3 = vrai ~~~
L'identité racine est créée paresseusement lorsque un site intégré en a besoin pour la première fois. Webship conserve la clé racine avec des permissions restrictives dans state_dir. Le certificat racine a une durée de vie de dix ans ; la durée de vie des feuilles est contrôlée par leaf_validity_days.
Traitez les deux emplacements de stockage comme un état de production :
- Le cache ACME contient des identités de site gérées automatiquement.
- Le répertoire d'état du CA intégré contient l'identité racine privée.
- Le compte de service a besoin d'accès, mais les utilisateurs de l'application non.
- Les sauvegardes doivent préserver la confidentialité et les permissions des fichiers.
- La production, le développement et les tests devraient utiliser des racines séparées et des répertoires séparés.
Supprimer le répertoire racine ne « réinitialise » pas le TLS. Cela crée une nouvelle ancre de confiance. Les clients qui font confiance à l'ancien root rejetteront les certificats émis par le remplaçant jusqu'à ce que leurs magasins de confiance soient mis à jour.
La fiducie privée est intentionnelle
Les certificats émis par l'autorité de certification intégrée ne sont pas automatiquement reconnus comme fiables par les navigateurs publics ou les systèmes d'exploitation. Ils ne deviennent fiables qu'après que l'opérateur a installé le certificat racine Webship exporté dans le magasin de confiance du client.
Cela fait du mode intégré un bon choix pour :
- ordinateurs portables et téléphones gérés par l'entreprise inscrits via la gestion des appareils ;
- trafic interne de service à service avec un bundle CA explicite ;
- appareils privés et flottes de périphérie contrôlées ;
- environnements de développement et de test qui doivent exercer un comportement TLS réel;
- réseaux déconnectés qui ne peuvent pas dépendre d'une autorité de certification publique.
Ce n'est pas le mode approprié pour un site web public ordinaire dont les visiteurs utilisent des navigateurs non gérés. Utilisez l'émission publique par site pour un nom public exact, l'émission de flotte pour de grands ensembles de sous-domaines publics, le partage uniquement pour un déploiement multi-SAN hérité délibéré, ou les fichiers manuels provenant d'une infrastructure PKI déjà fiable.
Distribuez uniquement le certificat racine aux clients. Ne distribuez jamais la clé privée racine. La possession de cette clé donne à son détenteur l'autorité d'émettre des identités reconnues par tous les clients enregistrés.
Les certificats publics et privés peuvent coexister
Webship 1.4.0 peut combiner des stratégies de certificat sur le même écouteur :
~~~toml écouter = "0.0.0.0:443"
[tls] unknown_sni = "rejeter"
[tls_automatique] activé = vrai directory_url = "https://acme-v02.api.letsencrypt.org/directory" cache_dir = "/var/lib/webship/acme" contacts = ["mailto:ops@example.com"] accepter_les_conditions_d'utilisation = vrai
[acme_ca] state_dir = "/var/lib/webship/acme-ca" leaf_validity_days = 90
[[sites]] domaine = "www.example.com" root = "/srv/public" certificate_mode = "par_site"
[[sites]] domaine = "control.internal.example" root = "/srv/control" certificate_mode = "intégré"
[[sites]] domaine = "payments.example.com" root = "/srv/payments"
[sites.tls] cert = "/etc/webship/payments-fullchain.pem" clé = "/etc/webship/payments-private-key.pem" ~~~
Ici, www.example.com reçoit son propre certificat ACME public. control.internal.example reçoit un certificat privé de l'AC intégré. payments.example.com reste sous la PKI externe de l’opérateur parce que ses fichiers explicites ont la priorité.
Le répertoire public ACME est ignoré par les sites intégrés. La racine intégrée ne signe jamais le site public. Le site manuel n'est jamais inscrit silencieusement dans aucun des flux de travail automatiques.
Un résolveur de certificat pour H1, H2, H3 et WebTransport
La sélection du certificat se fait pendant la poignée de main TLS, avant qu'une requête HTTP n'existe. Webship utilise le nom du serveur ClientHello pour sélectionner l'identité du site, puis négocie le protocole d'application.
- HTTP/1.1 et HTTP/2 utilisent TLS sur TCP.
- HTTP/3 et WebTransport utilisent TLS à l'intérieur de QUIC sur UDP.
- Une identité de site valide peut servir pour chaque protocole activé.
- HTTP/3 nécessite également la possibilité d'atteindre UDP ; H1 et H2 utilisent le chemin TCP.
- Alt-Svc peut annoncer H3 tout en conservant un repli TCP.
TCP, TLS et QUIC utilisent le même modèle d'identité sensible au site. Les noms exacts ont la priorité, le joker valide le plus long l'emporte lorsqu'il existe des certificats génériques configurés, et un SNI avec un nom inconnu peut être rejeté au lieu de recevoir un certificat par défaut non lié.
Utilisez unknown_sni = "reject" sur un écouteur multi-site lorsqu'un nom d'hôte non reconnu doit échouer de manière sécurisée. Testez les noms reconnus, les noms non reconnus et le comportement attendu sans SNI avant le déploiement en production.
Faire pivoter les identités intégrées sans intervalle de service
Webship expose l'état des certificats et les mutations contrôlées via son serveur MCP authentifié, lié en boucle locale :
- webship.tls.get_status rapporte le résolveur de certificat actif et l'état du renouvellement.
- webship.tls.reissue_certificate réémet immédiatement un site géré automatiquement uniquement lorsque ce site utilise le mode intégré.
- webship.tls.reload recharge l'état du certificat via le chemin TLS normal protégé.
- webship.acme_ca.status indique si la CA privée est sélectionnée, son répertoire d'état, la durée de vie des certificats terminaux, le nombre d'émissions, le nombre de révocations et un exemple récent de domaine.
- webship.sites.apply ajoute ou supprime des sites par rapport à une version de configuration épinglée.
Pour une réémission intégrée, Webship crée et valide le remplacement avant de l'intégrer au service. L'identité valide actuelle continue de servir jusqu'à ce que la nouvelle identité soit prête. L'identité retirée n'est enregistrée qu'après l'installation du remplacement.
L'opération de réémission immédiate rejette intentionnellement les certificats publics par site. Le renouvellement public doit rester à l'intérieur du cycle de vie public ACME plutôt que d'être confondu avec la signature privée en cours. L'appartenance en mode partagé est également gelée au redémarrage car le changement d'un groupe multi-SAN reconstruit la frontière d'identité.
Le MCP est une surface de contrôle privilégiée. Gardez-le en boucle locale, exigez TLS et un jeton porteur fort, utilisez un tunnel authentifié pour l'administration à distance et auditez chaque modification.
Limites de l'échec qui comptent
Un système de certificat sécurisé doit échouer dans la direction correcte.
- Un site intégré nouvellement configuré ne reçoit pas l'identité d'un autre site pendant que l'émission est en attente.
- Un remplacement invalide n'est pas installé sur un certificat fonctionnel.
- Les fichiers manuels explicites empêchent la propriété automatique de ce site.
- Un SNI nommé inconnu peut être rejeté avant le routage HTTP.
- La CA intégrée reste privée et n'a aucun point d'inscription à distance.
- Les identités publiques et intégrées utilisent des chemins de cache séparés à l'intérieur de l'état TLS automatique.
Un avertissement indiquant que le CA intégré n'est pas initialisé signifie que Webship n'a pas pu activer le répertoire d'état configuré. Corrigez la propriété, les permissions, la persistance ou la disponibilité du stockage avant d'envoyer du trafic vers le site concerné. Ne contournez pas l'erreur en copiant la clé racine d'un autre environnement.
Liste de contrôle de production
Avant d'activer le mode intégré :
- Identifiez toutes les populations de clients qui doivent faire confiance au site.
- Créez un processus contrôlé pour l'exportation et l'installation du certificat racine.
- Utilisez un état racine séparé pour la production, le développement et les tests.
- Persistez et protégez le répertoire d'état de l'AC intégrée et le cache TLS automatique.
- Exécutez Webship sous un compte de service dédié ayant accès uniquement au matériel clé requis.
- Sélectionnez certificate_mode sur chaque site dont la frontière de confiance doit être explicite.
- Définir et tester la politique SNI inconnue.
- Activez délibérément H1, H2 et H3 et vérifiez à la fois les chemins TCP et UDP.
- Exercice de réémission, de redémarrage, de sauvegarde, de restauration et de validation de confiance client en dehors de la production.
- Exécutez webship --check-config avant le déploiement, puis vérifiez l'émetteur, les noms, la validité, la chaîne et les protocoles négociés depuis un véritable client.
Choisissez d'abord la confiance, puis l'automatisation
L'AC intégrée supprime une dépendance à un service de certificats externe pour l'infrastructure privée. Elle ne rend pas une racine privée reconnue mondialement et elle ne supprime pas les responsabilités PKI de l'opérateur.
Webship automatise la génération de clés, la signature, la validation, l'installation, la rotation et la sélection de certificats à l'échelle du protocole. L'opérateur conserve toujours la garde du root, l'enregistrement des clients, la séparation des environnements, la sauvegarde, la récupération et la décision d'utiliser un chemin de confiance public ou privé.
Cette séparation est la caractéristique. Un serveur autonome peut automatiser le TLS privé sans prétendre être une autorité de certification publique — et les sites publics peuvent toujours utiliser l'émission par site ou par flotte approuvée par le navigateur dans le même processus.
Lisez la documentation versionnée Webship 1.4.0 avant le déploiement. La RFC 5280 définit les profils et la validation des certificats, la RFC 6066 définit le signalement du nom du serveur TLS, la RFC 8446 définit TLS 1.3, la RFC 8555 définit l'ACME public, et la RFC 9525 définit la vérification de l'identité des services.