Sécuriser le TLS interne avec des proxys ACME et la délégation DNS

Les environnements auto-hébergés ont souvent du mal à obtenir des certificats TLS valides pour des services non directement accessibles depuis Internet. Un récent guide technique publié par Sapiolab décrit une architecture robuste utilisant un proxy ACME et un serveur DNS dédié pour combler ce déficit de connectivité. Publié le 15 octobre 2026, cet article propose une méthode étape par étape permettant aux opérateurs de homelabs et aux petites équipes IT d'automatiser l'émission de certificats en toute sécurité.

Ce qui s'est passé

Le défi principal abordé est la limitation des méthodes de validation ACME standard pour les serveurs internes. Les défis HTTP-01 exigent que le serveur soit accessible depuis Internet public, ce qui est souvent impossible ou dangereux pour une infrastructure privée. Les défis DNS-01 nécessitent un accès API au fournisseur DNS autoritaire, ce qui pose des risques de sécurité si les identifiants sont exposés sur des machines internes. La solution proposée consiste à déployer un proxy ACME agissant comme intermédiaire entre les clients internes et les autorités de certification (CA) publiques.

Ce proxy convertit les demandes de validation internes en ordres DNS-01 externes. Pour éviter d'exposer les clés API du DNS principal, la configuration utilise un serveur DNS ACME séparé. Ce serveur local gère les enregistrements de défi grâce à une astuce de délégation CNAME, permettant aux CA publiques de valider la propriété du domaine sans accéder à la zone DNS principale. Le guide explique comment installer MariaDB, NGINX, Step CA et Unbound pour créer un pipeline de certificats entièrement automatisé et sécurisé.

Détails clés

• L'architecture utilise Step CA ou Lab-CA pour la gestion interne des certificats, Step CA étant noté pour être plus léger et plus simple à installer.
• Un proxy ACME traduit les requêtes HTTP-01 ou DNS-01 internes en ordres DNS-01 externes destinés à des CA publiques telles que Let’s Encrypt ou ZeroSSL.
• L'External Account Binding (EAB) permet de regrouper plusieurs comptes internes sous un seul compte externe, bien que le comportement de vérification de domaine puisse varier selon le fournisseur.
• Le DNS ACME sert de pont, hébergeant localement les enregistrements TXT _acme-challenge tandis que la CA publique suit un enregistrement CNAME pour les trouver.
• La configuration nécessite une structure DNS scindée (split-DNS) utilisant Unbound pour résoudre correctement les requêtes internes tout en déléguant les sous-domaines de défi.
• Les certificats privés évitent les journaux Certificate Transparency mais nécessitent l'installation manuelle du magasin de confiance sur chaque appareil client et image de conteneur.

Contexte

ACME est le protocole utilisé par la plupart des autorités de certification modernes pour automatiser l'émission de certificats TLS. Il repose sur des défis pour prouver la propriété du domaine. HTTP-01 place un fichier sur le serveur web, tandis que DNS-01 ajoute un enregistrement texte spécifique dans la zone DNS du domaine. Pour les serveurs internes, aucune de ces méthodes n'est simple car le serveur est caché derrière des pare-feu, et accorder l'accès API DNS à chaque service interne crée une surface d'attaque significative.

Les journaux Certificate Transparency sont des registres publics qui enregistrent tous les certificats publics émis. Bien que cela améliore la sécurité globale d'Internet, cela permet aussi aux attaquants de découvrir de nouveaux sous-domaines et services. Les autorités de certification privées évitent ces journaux mais introduisent une charge opérationnelle, car chaque appareil et application doit être configuré pour faire confiance au certificat racine privé. Cela est particulièrement difficile dans les environnements hétérogènes utilisant des conteneurs Docker ou des langages comme Python qui maintiennent leurs propres magasins de certificats.

Pourquoi c'est important

Pour les équipes exploitant des logiciels auto-hébergés, maintenir des certificats TLS valides est crucial pour la sécurité et la conformité. Des certificats expirés ou invalides cassent les intégrations, provoquent des avertissements dans les navigateurs et érodent la confiance des utilisateurs. L'automatisation de ce processus réduit la charge administrative pesant sur les ingénieurs DevOps qui pourraient autrement compter sur des scripts de renouvellement manuels ou des certificats statiques de longue durée. Le modèle de proxy ACME permet aux organisations d'utiliser des certificats publics fiables pour leurs services internes sans compromettre la sécurité réseau en ouvrant des ports entrants.

De plus, séparer le mécanisme de validation DNS du fournisseur DNS principal limite le rayon d'action d'une éventuelle fuite d'identifiants. Si un service interne est compromis, l'attaquant n'obtient qu'un accès limité au serveur DNS ACME, et non la capacité de modifier des enregistrements DNS critiques tels que les enregistrements MX ou A du domaine principal. Cette approche de défense en profondeur est essentielle pour les petites et moyennes entreprises qui gèrent leur propre infrastructure mais ne disposent pas de grandes équipes de sécurité.

Ce que vous pouvez faire

• Évaluez si vos services internes peuvent tolérer la charge opérationnelle liée à la gestion d'un magasin de confiance CA privé sur tous les clients.
• Déployez un proxy ACME tel que celui décrit avec Step CA pour gérer les demandes de certificats provenant des réseaux internes.
• Mettez en place une instance DNS ACME dédiée pour gérer les enregistrements de défi, évitant ainsi d'exposer les clés API du DNS principal.
• Configurez des enregistrements CNAME dans votre zone DNS publique pour déléguer les sous-domaines _acme-challenge vers votre serveur DNS ACME local.
• Implémentez un DNS à horizon scindé (split-horizon) à l'aide d'outils comme Unbound pour garantir que les clients internes résolvent correctement les services tandis que les validateurs externes peuvent atteindre les enregistrements de défi.
• Surveillez activement les dates d'expiration des certificats, car les systèmes automatisés peuvent encore échouer en raison de changements réseau ou de dérives de configuration.