Rédiger un tutoriel complet sur ce sujet n’est peut-être pas adapté à un site de Q/R, mais voici quelques conseils. De plus, ceci est du point de vue de la gestion de l’installation pour un seul client au sein de son propre intranet. Pour les installations SaaS par exemple, il est préférable d’utiliser des FQDN globaux et une PKI.
En tant qu’éditeur de logiciel, vous NE DEVEZ PAS :
-
implémenter votre propre PKI et la diffuser chez vos clients, car cela vous permet d’émettre des certificats pour des noms d’hôte arbitraires, vous donnant un mode Dieu sur l’ensemble de leur infrastructure.
-
utiliser les mêmes certificats auto-signés pour plusieurs clients avec des clés privées codées en dur, car elles peuvent facilement être extraites et utilisées contre d’autres clients.
-
combiner ces erreurs, car cela donnerait à chaque client un mode Dieu sur tous les autres clients.
Créez votre propre PKI au lieu de faire confiance à des certificats individuels
C’est principalement une considération de sécurité, mais c’est aussi plus facile à maintenir, puisque vous mentionnez avoir plusieurs installations sur plusieurs sites intranet.
Du point de vue de la sécurité, vous ne voulez pas que chaque application puisse signer des certificats pour des noms d’hôte arbitraires. Par conséquent, les certificats auto-signés individuels ne devraient pas tous être des autorités de certification de confiance.
Du point de vue de la maintenance, vous ne voulez pas mettre à jour vos stratégies et attendre leur propagation chaque fois que vous devez ajouter une nouvelle application web.
Bien que préférable, il n’est parfois pas possible (ou souhaité) d’obtenir des certificats d’autorités de certification externes. Les sites intranet peuvent ne pas avoir de FQDN globalement valides, rendant la vérification de domaine impossible, ou leur connectivité Internet est restreinte, rendant plus difficile la maintenance du renouvellement des certificats.
Dans ce cas, l’alternative recommandée est de créer une autorité de certification propre pour le client (ne diffusez pas votre PKI à plusieurs clients en tant qu’éditeur de logiciel) et de signer tous les certificats d’application avec elle. De cette façon, vous n’avez besoin d’ajouter qu’un seul certificat aux autorités de certification de confiance via la GP, et chaque certificat d’application signé avec sera approuvé.
Si vous n’avez besoin que d’une petite autorité de certification pour ce seul usage, vous pouvez utiliser OpenSSL :
Générez la clé racine (rootCA.key) et le certificat racine (rootCA.crt).
openssl genrsa -aes256 -out rootCA.key 4096
openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 7300 -out rootCA.crt
Gardez la clé en sécurité, de préférence hors ligne, et distribuez le certificat via la stratégie de groupe.
Créez un certificat pour votre application en commençant par une clé et une demande de signature de certificat (.csr).
openssl genrsa -out app.example.com.key 2048
openssl req -new -sha256 \
-key app.example.com.key \
-subj "/C=US/ST=CA/O=My Application/CN=app.example.com" \
-out app.example.com.csr
Créez un certificat d’application signé avec votre CA :
openssl x509 -req -in app.example.com.csr \
-CA rootCA.crt -CAkey rootCA.key -CAcreateserial \
-days 730 -sha256 \
-out app.example.com.crt
Utilisez app.example.com.key et app.example.com.crt dans votre application.
Pour des solutions plus lourdes, il y a Active Directory Certificate Services (AD CS), mais cela nécessite vraiment une planification, et vos compétences pourraient ne pas encore être suffisantes pour cela.
Utilisez une GPO au lieu de modifier la stratégie de domaine par défaut
En aparté, je ne modifierais pas la stratégie de domaine par défaut pour cela, mais créerais plutôt un nouvel objet de stratégie de groupe (GPO). Cela facilite grandement la limitation de la portée des modifications, par exemple en permettant de les appliquer d’abord à un groupe d’ordinateurs de test. Cela facilite aussi l’annulation des modifications en cas de problème.
Firefox a son propre magasin de certificats - il est possible d’utiliser les certificats de Windows
Le programme de certificats CA de Mozilla régit l’inclusion des certificats
racine dans Network Security Services (NSS), un ensemble de bibliothèques
open source conçues pour prendre en charge le développement multiplateforme
d’applications client et serveur sécurisées. Le magasin de certificats racine NSS
est utilisé dans les produits Mozilla tels que le navigateur Firefox,
et est également utilisé par d’autres entreprises dans divers produits.
Cela signifie que les certificats ajoutés au magasin de certificats Windows ne s’appliquent pas à Firefox par défaut. Pour une maintenance plus facile, il peut être judicieux de faire utiliser à Firefox les autorités de certification installées sur Windows. Utiliser son propre magasin de certificats est une bonne idée pour protéger la vie privée des individus utilisant Firefox, mais n’est pas très adapté aux environnements Windows AD. Heureusement, il existe un moyen de le désactiver.
En supposant que le répertoire d’installation de Firefox est C:\Program Files\Mozilla Firefox\, vous devez ajouter deux fichiers de configuration encodés en ANSI :
C:\Program Files\Mozilla Firefox\defaults\pref\local-settings.js contenant
pref("general.config.obscure_value", 0);
pref("general.config.filename", "ownsettings.cfg");
Ceci fait simplement référence au fichier suivant, contenant les paramètres de configuration réels.
C:\Program Files\Mozilla Firefox\ownsettings.cfg contenant
//
lockPref("security.enterprise_roots.enabled", true);
Il est important que les paramètres réels commencent à la deuxième ligne après // !
Ces fichiers peuvent être distribués via la même GPO en utilisant :
Computer Configuration \ Preferences \ Windows Settings \ Files