Création de ma propre autorité de certification pour un intranet
Je dois créer ma propre autorité de certification pour un intranet et, malheureusement, il ne semble pas y avoir de bonne réponse à ce sujet sur Security.SE.
Il existe de nombreuses ressources en ligne à ce sujet, mais toutes sont différentes et certaines utilisent des valeurs par défaut obsolètes (MD5/SHA1, etc.) qui ne semblent pas dignes de confiance. Il existe également des centaines de variantes différentes de openssl.cnf, allant d'un fichier de 10 lignes à l'énorme fichier fourni par défaut avec ma distribution.
Je voudrais une réponse canonique sur la configuration d'une autorité de certification simple pour l'émission de certificats serveur et de certificats client.
Apparemment, il semble que certaines personnes ne comprennent toujours pas que je ne suis pas une grande entreprise où un compromis CA cause des milliards de pertes et ne peut pas être atténué facilement, alors laissez-moi vous expliquer un peu mieux pourquoi j'ai besoin de l'AC:
plusieurs serveurs connectés via des liens non sécurisés (Internet) doivent communiquer en toute sécurité.
J'ai besoin d'un moyen de m'identifier sur ces serveurs afin d'effectuer des tâches administratives, sans aller et venir dans mon gestionnaire de mots de passe toutes les 10 secondes.
non autres autorités de certification que le mien devrait être en mesure de se faire passer pour l'un des serveurs, aussi improbable soit-il ( mais possible ).
Là. Ma propre PKI et un certificat installé sur chaque machine semblent parfaitement correspondre aux besoins. L'un des logiciels que j'utilise nécessite également l'utilisation d'une PKI, donc l'utilisation de certificats auto-signés n'est pas une option.
Pour compromettre la PKI, quelqu'un devrait compromettre ma machine de travail, et si cela est fait, l'attaquant peut déjà faire pas mal de dégâts sans même toucher la PKI (car je me connecterais via SSH au serveur depuis cette machine de toute façon) . C'est un risque que j'accepte de prendre, et cette ICP n'ajoute pas plus de risque que ce qui existe déjà.
Si votre infrastructure est minuscule , la plupart des détails de l'exécution d'une autorité de certification (par exemple, les listes de révocation de certificats et autres) peuvent probablement être ignorés. Au lieu de cela, tout ce dont vous avez vraiment à vous soucier, c'est de signer des certificats.
Il existe une multitude d'outils qui géreront ce processus pour vous. J'en ai même écrit un il y a plusieurs années. Mais celui que je recommande si vous voulez quelque chose de vraiment simple est easy-rsa du projet OpenVPN. C'est un wrapper très fin autour de l'outil de ligne de commande OpenSSL. Si vous allez gérer BEAUCOUP de certificats et réellement traiter la révocation et d'autres choses, vous voudrez un utilitaire beaucoup plus complexe et complet. Il y a plus qu'assez de suggestions déjà fournies, donc à la place, je m'en tiendrai aux bases de ce que vous essayez d'accomplir.
Mais voici la procédure de base. Je vais l'expliquer avec OpenSSL, mais n'importe quel système fera l'affaire.
Commencez par créer votre autorité de certification "racine" - ce sera un certificat auto-signé. Il y a plusieurs moyens de le faire; c'est un. Nous ferons du nôtre un certificat de 10 ans avec une clé de 2048 bits. Ajustez les chiffres comme il convient. Vous avez mentionné que vous craigniez l'algorithme de hachage, j'ai donc ajouté -sha256 pour vous assurer qu'il est signé avec quelque chose d'acceptable. Je crypte la clé en utilisant AES-256, mais c'est facultatif. Il vous sera demandé de remplir le nom du certificat et autres; ces détails ne sont pas particulièrement importants pour une autorité de certification racine.
# First create the key (use 4096-bits if that's what floats your boat)
openssl genrsa -aes256 -out root.key 2048
# Then use that key to generate a self-signed cert
openssl req -new -x509 -key root.key -out root.cer -days 3652 -sha256
Si vous avez chiffré la clé à la première étape, vous devrez fournir le mot de passe pour l'utiliser à la seconde. Vérifiez votre certificat généré pour vous assurer que sous "Contraintes de base" vous voyez "CA: TRUE". C'est vraiment le seul élément important dont vous devez vous soucier:
openssl x509 -text < root.cer
Cool. OK, nous allons maintenant signer un certificat. Nous aurons besoin d'une autre clé et cette fois d'une demande. On vous demandera à nouveau votre nom et votre adresse. Les champs que vous remplissez et ce que vous fournissez dépendent de vous et de votre demande, mais le champ qui compte le plus est le "Nom commun". C'est là que vous fournissez votre nom d'hôte ou votre nom de connexion ou tout ce que ce certificat va attester.
# Create new key
openssl genrsa -aes256 -out client1.key 2048
# Use that key to generate a request
openssl req -new -key client1.key -out client1.req
# Sign that request to generate a new cert
openssl x509 -req -in client1.req -out client1.cer -CA root.cer -CAkey root.key -sha256 -CAcreateserial
Notez que cela crée un fichier appelé root.srl pour garder nos numéros de série droits. Le -CAcreateserial flag indique à openssl de créer ce fichier, vous devez donc le fournir pour la première demande que vous signez puis plus jamais. Et encore une fois, vous pouvez voir où ajouter le -sha256 argument.
Cette approche - tout faire manuellement - n'est à mon avis pas la meilleure idée. Si vous exécutez une opération importante, vous voudrez probablement un outil capable de garder une trace de tous vos certificats pour vous.
Au lieu de cela, mon propos ici était de vous montrer que la sortie que vous souhaitez - les certificats signés comme vous le souhaitez - ne dépend pas des outils que vous utilisez, mais plutôt des options que vous fournissez à ces outils. La plupart des outils peuvent produire une grande variété de configurations, à la fois fortes et faibles, et c'est à vous de fournir les chiffres que vous jugez appropriés. Les valeurs par défaut obsolètes sont normales pour le cours.
Il n'y a aucun moyen de le faire simplement. il existe des outils qui peuvent vous aider à démarrer facilement.
comme:
aucun d'entre eux n'est une PKI complète à part peut-être EJBCA mais ce n'est pas trivial à configurer.
- XCA est un petit outil frontal pour obtenir une interface graphique pour générer, signer et révoquer des certificats.
- EJBCA ou Enterprise Java Beans Certificate Authority est une JBOSS/Jetty Webapp qui peut faire l'infrastructure PKI complète pour une entreprise.
- openssl est l'outil de ligne de commande de base. il peut effectuer tous les bits hors ligne d'une autorité de certification, mais aucune vérification (prête à l'emploi). vous pouvez créer vos propres vérificateurs OCSP avec, mais vous devez créer vous-même le code "en ligne".
Si tout ce que vous recherchez est une configuration opensl appropriée. XCA peut vous aider à les générer. (il a une fonction d'exportation de configuration openssl
Si vous souhaitez vraiment être un CA, tenez compte des implications de sécurité de le faire.
- La clé privée utilisée pour générer l'autorité de certification racine pour votre intranet doit littéralement être verrouillée dans un coffre-fort. Et l'accès à ce coffre-fort doit être surveillé physiquement.
- L'utilisation d'une autorité de certification racine auto-signée oblige vos utilisateurs à non seulement croire que vous effectuez une diligence raisonnable avec la protection sécurisée des clés, mais également à insérer une boîte racine initialement non approuvée dans leur chaîne de certificats.
- Cela rompt également la fonctionnalité d'agrafage OSCP en ce qui concerne la vérification externe de la chaîne de certificats, raison pour laquelle les services de gestion des identités existent en premier lieu.
Un grand nombre d'entre eux contesteraient le raisonnement derrière la gestion de votre propre autorité de certification, par exemple; c'est pour un intranet d'entreprise où une partie de nos builds de bureau incluent la racine ca ou c'est pour un petit nombre d'utilisateurs.
Bien qu'il ne soit pas nécessairement faux de le faire et puisse offrir certains avantages, cela annule la chaîne de vérification pour laquelle la gestion de l'identité basée sur les certificats a été conçue.
Si vous décidez d'implémenter votre propre autorité de certification racine, assurez-vous de suivre les mêmes pratiques de sécurité que toute autre autorité de certification racine. En tant qu'entreprise, la dernière chose que vous souhaiteriez, c'est que quelqu'un compromet la clé privée utilisée pour votre autorité de certification racine et commence à signer des certificats pour des campagnes de phishing contre vos clients.
Il existe des tonnes de guides de bonnes pratiques disponibles à cet effet, le NIST (institut national des normes et de la technologie) est un groupe collaboratif aidant à diverses normes pour les sujets de sécurité informatique.
Lecture recommandée:
Audit (PDF)
Reprise après sinistre (PDF)
Systèmes à clé publique (PDF)
Sans institute concernant les petits déploiements PKI
Ok je vois que vous avez mis à jour votre question pour être plus précis.
Deux documents pour configurer votre fichier openssl.cnf pour les spécificités de l'autorité de certification:
https://www.openssl.org/docs/apps/ca.html
https://www.openssl.org/docs/apps/config.html
Je me rends compte que ce n'est peut-être pas la réponse que vous voulez mais parce que l'environnement et les exigences de chacun sont différents, vous devrez définir une portée pour votre implémentation de CA pour un bon exemple de configuration.
Pour de bons antécédents, veuillez consulter ma présentation Comment créer et exploiter votre propre centre de gestion de certificats de médiocrité. L'essentiel de la présentation est que la chose la plus requise n'est pas une liste des commandes à exécuter, mais plutôt une compréhension approfondie de tous les différents contrôles nécessaires à l'exploitation d'une autorité de certification commerciale, comment ils interagissent ensemble, l'impact exact de la suppression l'un d'eux, l'impact cumulatif de la suppression de plusieurs d'entre eux et les mesures d'atténuation nécessaires pour compenser la sécurité réduite.
C'est pourquoi il n'y a pas de "réponse canonique à propos de la configuration d'une autorité de certification simple". Soit vous suivez l'intégralité de la route ISO, en commençant par une partie signataire clé, des certificats racine dupliqués airgapped et vault, plusieurs signataires intermédiaires, des serveurs de révocation, etc., etc., ou bien vous devez concevoir un compromis basé sur le rapport coût/avantage unique et profil de risque que l'entreprise est prête à accepter. Quiconque possède suffisamment de compétences et d'expérience pour effectuer cette évaluation par définition n'a pas besoin de la feuille de triche. Ils peuvent analyser la syntaxe de commande correcte sur la base d'une compréhension approfondie de la fonction métier à accomplir et des primitives de sécurité utilisées pour implémenter cette exigence.
Dans la présentation, il y a des histoires de véritables fiançailles de magasins qui ont emprunté cette voie et se sont terriblement trompés. Dans certains cas, mon évaluation a indiqué que rien de ce que je pouvais faire avec la sécurité de votre middleware ne pouvait surmonter les faiblesses inhérentes à l'autorité de certification interne. Aux États-Unis, quiconque devrait se rendre compte qu'il achète probablement des services à au moins un des fournisseurs auxquels la présentation fait référence. Ce sont les banques, les coopératives de crédit, les assureurs-maladie, les détaillants et plus encore.
Étant donné que pour que les recommandations soient "correctes", le répondeur doit faire des hypothèses majeures sur vos profils de risque acceptables et que vous devez faire des hypothèses majeures sur le degré d’alignement et de synchronisation de vos idées et de leurs risques, la proposition même est risqué sur son visage. Dans la plupart des cas, l'évaluation de l'adéquation des tutoriels fournis a plus à voir avec la présentation qu'avec le niveau de sécurité effectif résultant du respect de leurs procédures. S'il est bien organisé et clairement articulé, cela importe BEAUCOUP plus que s'il est efficace. Nous choisissons la feuille de triche canonique qui nous semble la meilleure.
Pour ces raisons, je ne pense pas qu'un expert crédible puisse fournir "des informations correctes et à jour openssl.cnf files ", mais pourrait au mieux fournir un processus d'évaluation pour évaluer plus complètement les exigences et le risque acceptable. Puisque vous pariez sur le résultat, aucun expert crédible ne le ferait en dehors de la protection d'un contrat. Toutes recommandations que vous obtenez devrait, presque par définition, provenir d'un expert crédible. Bonne chance.
Suivez ces instructions pour configurer une Windows Based CA . Étant donné que vous émettez des certificats clients, sachez que les hachages SHA2 ne sont pas pris en charge sur XP.
La réponse simple est de:
- Installer AD
- Installer une autorité de certification d'entreprise sur le contrôleur de domaine
- Modifier le modèle de certificat pour émettre des certificats d'utilisateur final (définir l'autorisation pour les utilisateurs de s'auto-inscrire ou d'accéder à une page Web)
- Déployer la clé publique du certificat racine sur tous les serveurs qui valident les utilisateurs
- Si les utilisateurs sont sur AD, utilisez GPO pour activer l'inscription automatique