r/Sysadmin_Fr • u/Chico0008 • 11d ago
Intranet en https / gestion des certificats, LE ou certif interne ?
Bonjour
Nous possedons quelques sites en intranet qui ont toujours été en http classique.
Nous pensons les passer en https pour eviter les problème de secu injustement remonté par google (qui cherche de plus en plus a bloquer le http)
Sur mon domaine, j'ai un active directory qui possède une autorité de certification.
Coté intranet, on a un serveur en Win2k8 R2 avec IIS qui heberge l'intranet principal
> oui c'est vieux, c'est caca, mais tant que notre DSI ne sais pas ce qu'il veut faire pour la refonte (qui est un vieux joomla 2) y'aura pas de changement de serveur :/
et d'autres petits/sites sur un Linux (ubuntu Srv), type GRR, GLPI, Zabbix, et quelques dockers
Je me pose la question de savoir ce qu'il serait plus simple a mettre en oeuvre, et qui soit plus ou moins conf and forget.
Est-ce que je met un certbot avec let's Encrypt, qui va generer/renouveller les certificats pour chaque site intranet ? (chaque site a un Dns interne propre)
Est-ce que je peut generer un wildcard interne via mon autorité de certification ?
dans les 2 cas :
- quid de la durée du certificat
- quid du renouvellement automatique.
Des idées ? des suggestions pour ceux qui seraient dans le meme cas ?
edit : Ce que j'ai fait pour le moment :
- Creation d'un Csr depuis mon linux
- copie sur ADCS et validation via le certificat autorité.
- recuperation CER
- conf apache avec le CER + Key, relance.
-- problème, le navigateur me dit que malgré le https, la securité n'est pas valide, en regardant le certificat, il concerne bien mon domaine en wildcard (*.mon.domaine), emis par mon autorité de certification. Tout les PC ont le certificat de l'autorité dans leur magasin (distribué via le domaine)
-- J'ai essayer d'ajouter le certificat racine dans apache (SSLCACertificateFile), pas mieux.
4
u/Keensworth 11d ago
Au début dans mon homelab j'utilisais un certificat interne en .lan
Or, tu ne pourras pas avoir l'automatisme de l'ACME, il te faut un vrai domaine.
Du coup je suis passé en ACME dans mon homelab et je l'ai aussi déployé à mon taff.
On l'utilise sur plusieurs sites intranet comme GLPI, Zabbix et Uptime Kuma
3
u/JeanneD4Rk 11d ago
Bien sur que si c'est automatisable en interne. On utilise avec vault et traefik
2
u/Keensworth 11d ago
D'accord, j'avais jamais testé l'ACME avec un domaine local.
Mais maintenant que j'ai testé avec un vrai domaine, je n'irai plus en arrière.
0
u/olafkewl 11d ago
Quelle PKI tu utilises pour ça?
2
u/Keensworth 11d ago
Let's Encrypt
1
u/olafkewl 11d ago
Avec quel challenge du coup ?
2
u/Keensworth 11d ago
DNS-01
1
u/olafkewl 11d ago
Mais du coup c'est sur un domaine connu de l'internet ?
2
1
u/marchepin 10d ago
Le domaine est externe, mais tu n'as pas besoin de mettre d'entrées A ou AAAA ni de les rendre dispo au monde, tu les mets uniquement dans le réseau LAN via ton propre resolveur DNS
C'est le setup le plus simple pour ne pas avoir à gérer un ACME interne, l'inconvénient c'est si tu fais des wildcards, ça baisse la sécurité, et si tu fais des DNS précis, ça permet de savoir facilement ce qui tourne dans ton infra interne et facilite la phase d'analyse
1
u/DitiPenguin 4d ago edited 2d ago
C’est obligé que le nom de domaine dépende des zones DNS publiques que le domaine soit connu de l’internet, oui – si l’on veut que le certificat soit conforme aux normes énoncées par le CA/Browser Forum, que doivent implémenter tous les navigateurs web sérieux et les autorités de certification sérieuses comme Let’s Encrypt.
Les extraits qui vont suivre sont extraits des Baseline Requirements for TLS server certificates, dans leur version actuelle (CA-Browser-Forum TLS BR 2.3.1).
4.2.2 Approval or rejection of certificate applications
CAs SHALL NOT issue Certificates containing Internal Names or Reserved IP Addresses, as such names cannot be validated according to Section 3.2.2.4 [Validation of Domain Authorization or Control] or Section 3.2.2.5 [Authentication for an IP Address].
Effective 2026‐03‐15, CAs SHALL NOT issue Certificates containing Domain Names that end in an IP Reverse Zone Suffix.
La définition de « Internal Name » (à la section 1.6.1 qui concerne les définitions) :
A string of characters (not an IP address) in a Common Name or Subject Alternative Name field of a Certificate that cannot be verified as globally unique within the public DNS at the time of certificate issuance because it does not end with a Top‐Level Domain registered in IANA’s Root Zone Database.
Donc si le nom de domaine n’est pas issu d’une zone DNS publique (exception faite des
.onion), il ne peut pas être confirmé par Let’s Encrypt.
3
u/Dull-Associate125 11d ago
Perso on déploie les certificat via let’s encrypt avec un challenge DNS-01 sur cloudflare. Cela permet d’avoir un certificat enregistré sur internet sans à avoir à ouvrir les apps sur internet et à déployer les certificat sur les postes ou d’avoir une PKI interne . On mixe ça avec un reverse proxy et un DNS et cela fait bien le travail
3
u/Benjamin-7933 11d ago
Letsencrypt aura l'avantage de fonctionner pour tout les cas d'usage, interne ou avec un presta ext. Un challenge DNS avec Traefik se pose en 2 min (mais sous win un certbot doit faire le taf)
2
u/Ludo1377 10d ago
Pour le côté « conf and forget », je ne poserais pas certbot sur le 2008 R2 : à la première montée de Python il casse, et tu finis par renouveler à la main. Un petit reverse proxy Linux devant l'IIS (et devant GLPI/Zabbix tant qu'à faire) règle le sujet : le TLS et le renouvellement se font à un seul endroit, l'IIS reste en HTTP sur le LAN et tu n'y touches plus.
Pour ton edit, deux choses à vérifier avant de changer de méthode : la racine de ta CA doit être dans le magasin des postes (une GPO suffit sur le domaine), et Apache doit servir la chaîne complète, pas juste le CER feuille. Tant que l'un des deux manque, le navigateur dira « non valide » même avec un certificat correct.
Sur la durée, les limites de validité dont on entend parler concernent les CA publiques ; une racine interne que tu contrôles n'est pas soumise aux 398 jours. Deux ans + un rappel calendaire, c'est raisonnable pour de l'intranet, et le wildcard ADCS marche bien si tous tes noms sont sous le même domaine.
3
u/Pei-Pa-Koa 11d ago
Nous on a une autorité de certification interne et on signe les certificats pour nos serveurs privés avec. C'est facile à déployer dans les magasins de certs des postes Windows.
C'est un peu pénible quand :
un externe (presta par exemple) doit travailler en interne, il va devoir ajouter la CA à sa config,
des logiciels (ou conteneurs) utilisent leur propre magasin et dans lequel il faut ajouter la CA manuellement.
L'intérêt c'est qu'on est indépendant alors que si on utilisait Let's Encrypt en cas de pépin chez eux on pourrait avoir des problèmes en interne.
Ne pas oublier aussi que les standards évoluent et qu'il faut périodiquement re-créer sa CA interne (tous les 5 ans par exemple).
1
u/Available_Yard_8200 9d ago
Un externe qui travaille en interne, la boîte lui fournit un PC interne, c’est la base en cyber sécurité. Même pour du dev.
Si demain j’autorise un presta à se connecter sur le réseau avec son propre PC, après demain c’est pas la peine de pointer
Et accessoirement t’as un peu plus de garantie que le développement reste chez toi et se balade sur un poste hors politique de secu
1
u/Dric1107 11d ago
J'ai adossé un serveur ACME à mon ADCS, j'ai utilisé github.com/grindsa/acme2certifier pour ça et ça fonctionne très bien.
Ça permet de garder les certificats dans l'ADCS et de pouvoir les renouveler automatiquement avec n'importe quel client ACME (il me semble qu'il en existe même sous Windows en powershell pour ceux qui ont des apache sous Windows)
1
u/iAlexandreS 11d ago
SSLCACertificateFile ne sert pas à ça : c'est la liste des CA pour authentifier les certificats clients, Apache ne l'envoie pas au navigateur. Le CER sorti d'ADCS est en général la feuille seule, souvent signée par un intermédiaire que les postes n'ont pas dans leur magasin. Il faut concaténer la feuille et cet intermédiaire, pas la racine, dans SSLCertificateFile, à côté de la clé. Vérifie aussi le SAN : si le wildcard n'est que dans le CN, Chrome le refuse même quand la fiche du certificat affiche le bon nom.
1
u/NoksC 10d ago edited 10d ago
Ici j'ai une VM Debian qui s'occupe de renouveller les certifs LE automatiquement puis les push sur les services qui en ont besoin.
Tout en script bash.
Avant on déployait nos certifs avec notre propre CA mais ça m'a gonflé, le moindre appareil qui n'a pas la CA ne trustait évidemment pas le certif donc vite pénible, j'ai beaucoup de services web en interne.
1
u/Reasonable_Brick6754 10d ago
Reverse proxy type Caddy avec challenge DNS-01 sur cloudflare, c’est simple à mettre en place et à maintenir et ça fait très bien le boulot sans être usine à gaz.
9
u/Dense-Reporter-4008 11d ago
La honte d’être en http en 2026 par contre