Retour aux projets

Projet 4

Une PKI interne avec AD CS

Le problème que je voulais résoudre

Plusieurs services de mon lab (l'interface de pfSense, Zabbix, la liaison LDAP vers l'AD) utilisaient des certificats auto-signés, ou pas de chiffrement du tout. Résultat : avertissements « connexion non sécurisée » partout, et surtout des mots de passe qui pouvaient circuler en clair.

Mon raisonnement

Plutôt que de bricoler service par service, je voulais une autorité de certification interne unique qui signe tous les certificats du domaine — comme en entreprise. Une fois la confiance dans cette autorité déployée sur le parc, tous les services signés par elle sont reconnus sans avertissement.

Ce que j'ai mis en place

  • Le rôle AD CS sur le contrôleur de domaine, configuré en autorité de certification d'entreprise (FSEC-CA).
  • Des certificats signés par cette autorité pour pfSense (interface web en HTTPS), pour Zabbix (accès web chiffré) et pour la liaison LDAPS entre l'AD et les applications.
  • Le déploiement de la confiance dans FSEC-CA sur tout le parc : par GPO pour les machines Windows, par update-ca-certificates pour les machines Linux.

Pourquoi LDAPS et pas LDAP simple

LDAP (port 389)LDAPS (port 636)
ChiffrementAucun — mot de passe en clairSSL/TLS
Windows Server 2025Refusé par défautAccepté
Pour le dossierMauvaise pratiqueBonne pratique, recommandée ANSSI

Comment j'ai validé

Depuis un poste du domaine, après application de la GPO, l'accès à l'interface de pfSense affiche un cadenas vert, sans avertissement. La liaison LDAPS est testée en ligne de commande avant d'être déclarée opérationnelle dans les applications.

Outils
  • AD CS
  • PKI
  • Certificats SSL/TLS
  • LDAPS
  • GPO
  • pfSense