Let's Encrypt pour les sites intranet?
De nombreuses entreprises ont des sites intranet qui ne sont pas accessibles via Internet. Habituellement, ils utilisent simplement un certificat auto-signé, ce qui provoque une mauvaise habitude pour les utilisateurs car ils s'habituent à simplement appuyer sur OK sur les avertissements CERT invalides.
Question: Comment peuvent-ils générer un certificat pour leurs sites Web HTTPS en utilisant Let's Encrypt? Les navigateurs Web LTS ont-ils le Let's Encrypt as CA?
N'est-ce pas un problème de confidentialité que des noms de domaine privés, comme my-company-private-intranet-site.com, pourraient être divulgués?
Let's Encrypt ne peut émettre que des certificats pour des noms DNS valides. Donc, si votre intranet utilise un nom de domaine composé comme intranet.mycompany.local alors ça ne marchera pas.
Si vous avez un vrai nom DNS comme intranet.mycompany.com (même s'il ne se résout pas en externe sur votre intranet), vous pouvez alors utiliser Let's Encrypt pour émettre des certificats. Si le domaine résout en externe sur un serveur qui peut répondre sur le port 80 (qui ne doit pas réellement faire partie de votre intranet, si vous avez DNS à horizon partagé ), vous pouvez utiliser le http-01 défi.
Vous pouvez également utiliser le dns-01 challenge (entièrement pris en charge dans Certbot 0.10. et versions ultérieures, ainsi que d'autres clients tels que déshydraté , getssl et - acme.sh ). Étant donné que ce défi fonctionne en provisionnant les enregistrements DNS TXT, vous n'avez jamais besoin de pointer un enregistrement A vers une adresse IP publique.
Il n'est donc pas nécessaire que votre intranet soit accessible depuis Internet, mais votre nom de domaine doit exister dans le DNS public sous votre contrôle.
Let's Encrypt - et les autorités de certification de confiance du public en général, en raison de exigences de Chrome - soumettre tous les certificats émis aux journaux de transparence des certificats publics. En tant que tel, vous ne devez pas vous attendre à ce que votre (sous) nom de domaine intranet reste secret si vous obtenez un certificat pour celui-ci. De toute façon, la sécurité de votre intranet ne devrait pas dépendre de la confidentialité de son nom de domaine.
Si vous recherchez un service interne de type autorité de certification pour un intranet, une autorité de certification publique comme Lets Encrypt peut ne pas fonctionner, car elle souhaite se reconnecter à ses serveurs pour gérer la demande de certificat et la signature. Cela suppose que vous n'avez pas accès à Internet depuis votre serveur Web intranet; vous devez installer un client sur le serveur Web pour qu'il communique avec le service Lets Encrypt.
Comment peuvent-ils générer un CERT pour leur site Web HTTPS à l'aide de Let's Encrypt?
LE a un client dédié à cet effet. Voir comment cela fonctionne
Les navigateurs Web LTS ont-ils le Let's Encrypt as CA?
Il existe une prise en charge limitée des certificats racine de l'AC prêts à naviguer; voir https://github.com/letsencrypt/letsencrypt#disclaimer . Ils ont des certificats publics sur le site à https://letsencrypt.org/certificates/
Revenons à votre point principal, à savoir l'émission de certificats SSL acceptés par le navigateur qui ne génèrent pas d'avertissements. Comme RoraZ le suggère, les utilisateurs doivent importer le certificat auto-signé de l'entreprise pour éliminer les avertissements récurrents du navigateur et empêcher les utilisateurs de prendre l'habitude d'accepter simplement des certificats non valides.
Nous utilisons OpenSSL pour nous permettre de fonctionner comme notre propre autorité de certification, générant une autorité de certification racine que tous les utilisateurs doivent importer, nous permettant ainsi de générer des certificats supplémentaires qui seront automatiquement acceptés par le navigateur de tous les employés, ou tout service reposant sur SSL. C'est différent que de simplement importer le certificat auto-signé si nécessaire; vous créez en fait un certificat racine CA et vous l'importez. À l'avenir, vous pouvez émettre n'importe quel nombre de certificats pour différents noms communs, signés par cette autorité de certification, et ils sont valides et approuvés via votre propre autorité de certification racine privée.
Pour créer et gérer votre propre autorité de certification, voir http://www.flatmtn.com/article/setting-openssl-create-certificates
MISE À JOUR 2019-03-30: Quelqu'un a en fait trouvé un moyen à grande échelle de faire LE pour les serveurs internes: https://blog.heckel.xyz/2018/08/05/issuing-lets-encrypt-certificates-for -65000-serveurs-internes /
——————-
Comment peuvent-ils générer un CERT pour leur site Web HTTPS à l'aide de Let's Encrypt?
Pas du tout. Ceci est pour les sites accessibles au public uniquement .
( Mise à jour 2016-04-22: Peut-être "pas du tout" est un peu trop difficile. Voici un peu plus de détails: LE est adapté aux sites accessibles au public. Vous avez besoin d'un serveur qui répond au nom DNS lorsque LE vient vous le demander. Maintenant, si vous avez configuré votre serveur DNS pour donner des réponses différentes selon la personne qui pose réellement la question - quelqu'un de l'intérieur ou de l'extérieur aka Split-Brain-DNS - alors vous pouvez rediriger la demande de vérification vers n'importe quel hôte que vous vouloir. - Mais ce n'est pas un cas d'utilisation avec lequel LE vous aide vraiment. Au contraire: En 2015, il y avait cette intention explicite: "nous prévoyons de changer fréquemment l'ensemble d'adresses IP à partir desquelles nous validons" . - Ainsi, il vous est pratiquement impossible de simplement mettre en liste blanche les adresses IP des hôtes de validation LE sur votre pare-feu, car ces adresses IP peuvent souvent changer.
Les navigateurs Web LTS ont-ils le Let's Encrypt as CA?
Oui. Leur CA est signée par un CA bien connu et bien établi. (À savoir par IdenTrust .) Ainsi, tous les clients qui font confiance à cette ancienne autorité de certification feront également confiance à la nouvelle autorité de certification Let's-Encrypt immédiatement.
Pour une solution appropriée, vous pouvez exécuter une propre instance boulder , c'est-à-dire la partie serveur letsencrypt, sur votre réseau. Ensuite, vous pouvez utiliser tous les clients officiels et non officiels avec votre propre serveur ACME s'ils prennent en charge l'utilisation de différentes URL ACME (les URL officielles le font, pour les autres, vous devez le rechercher dans leur documentation ou leur code source).
Vous devez ensuite importer le certificat CA dans le magasin de clés de confiance des clients utilisant vos serveurs.
Si vous n'avez que quelques serveurs exécutant boulder et que "letsencrypt" n'est pas le meilleur choix et vous pouvez utiliser des outils plus simples comme easy rsa .
les personnes suggérant de mettre des noms internes dans une autorité de certification publique devraient consulter les journaux de transparence des certificats publics et comprendre que cela fuit des informations sur les noms des systèmes internes sur Internet
https://blog.appsecco.com/certificate-transparency-part-3-the-dark-side-9d401809b025https://www.ssl.com/faqs/questions- about-certificate-transparence /
Je suggère, vous lisez les solutions possibles. La meilleure solution serait d'implémenter votre propre infrastructure à clé publique (PKI) dans votre organisation. Cela évitera que vos hôtes internes ne soient répertoriés dans un journal CT géré par une autorité de certification publique.
C'est juste une autre chose qu'un attaquant potentiel devrait découvrir que vous avez rendu plus difficile en ne divulguant pas vos noms.
Tant que vous possédez les vrais domaines et que vous n'en voulez pas pour des domaines comme l'hôte local ou les adresses IP du réseau interne, vous pouvez en générer un sur Internet public, en pointant vers un système vierge, puis le transférer sur votre intranet à l'aide de rsync ou similaire.
Vous pouvez même maintenant obtenir un caractère générique, donc *.internal.yoursite.extension pourrait fonctionner. Il est évidemment inutile pour les sites d'usurpation d'identité comme Microsoft.com.
Je peux comprendre pourquoi les sites d'usurpation d'identité ne sont pas souhaitables, mais je peux également voir comment il peut être utile de ne pas avoir à installer d'autorité de certification sur chaque poste de travail de l'organisation.