Pourquoi Windows 2012 R2 ne fait-il pas confiance à mon certificat auto-signé?

Dans un environnement de test, je suis actuellement empêché de tester certaines choses qui doivent être déployées bientôt (en fait déjà, mais vous savez comment les délais se déroulent ...) parce que Windows refuse de faire confiance au certificat auto-signé que nous avons dans notre environnement de test isolé. Alors que je pouvais juste contourner le problème avec le "vrai" certificat et quelques astuces DNS, pour des raisons de sécurité / compartimentation, je n'ai pas dit le certificat.

J'essaie de me connecter à un serveur de messagerie basé sur Linux appelé Zimbra; il utilise un certificat OpenSSL autosigné généré automatiquement. Bien que les pages que Google a publiées se réfèrent spécifiquement aux sites Web IIS avec des certificats auto-signés IIS, je ne pense pas que la méthode pour les générer importe vraiment.

Selon les instructions que j'ai trouvées ici et ici , cela devrait être une simple question d'installation du certificat dans le magasin Trusted Root Certification Authority de l'ordinateur local. Ce que j'ai fait, ainsi que copier manuellement le certificat et l'importer directement via le composant logiciel enfichable MMC. Les déconnexions et redémarrages ne changent rien.

Voici l'erreur de certificat que j'obtiens à chaque fois:

Et voici le chemin de certification (spoiler: c'est juste le certificat lui-même):

Enfin, voici le certificat caché en toute sécurité dans le magasin de certificats de l'ordinateur local, exactement comme les instructions que j'ai trouvées disent qu'elles devraient être:

Ces instructions font spécifiquement référence à Vista (enfin, la seconde ne mentionne pas OS) et IIS, tandis que j'utilise Server 2012 R2 pour se connecter à un serveur Linux; il y a quelques différences dans l'assistant d'importation (comme le mien a la possibilité d'importer pour l'utilisateur actuel ou le système local, bien que j'aie essayé les deux), alors peut-être qu'il y a quelque chose de différent que je dois faire ici? Un paramètre quelque part que je n'ai pas trouvé qui doit être changé pour qu'il fasse vraiment confiance au certificat que je lui ai déjà dit de faire confiance?

Quelle est la bonne façon de faire en sorte que Windows Server 2012 R2 approuve un certificat auto-signé?

L'erreur que vous recevez n'est pas qu'il ne s'agit pas d'un certificat racine approuvé, mais qu'il n'est pas en mesure de vérifier la chaîne vers un certificat approuvé. Si une partie de la chaîne est cassée, non fiable ou manquante, vous recevrez une telle erreur. L'erreur que j'obtiens avec une racine non fiable et auto-signéeest le suivant: ce certificat racine d'autorité de certification n'est pas approuvé. Pour activer la confiance, installez ce certificat dans le magasin des autorités de certification racines de confiance. Mais pour vous, il dit qu'il ne peut pas vérifier jusqu'à un certificat racine de confiance. Cela peut être dû au fait que pendant le processus d'auto-signature, vous avez peut-être demandé à openssl de signer le certificat avec une racine différente (pas d'auto-signature), ou il n'a peut-être pas été défini en tant qu'autorité de certification racine. S'il s'agit du premier, vous devez plutôt faire confiance à la racine avec laquelle il a été signé. Si c'est le dernier, il s'agit de définir quelques propriétés dans openssl.conf.

d'après ce que je peux comprendre, vous devez ajouter zmaster en tant qu'autorité de certification source fiable car c'est l'autorité émettrice, WS2k12 essaie de vérifier le certificat par rapport à un hôte dont il ne sait rien. Vous avez raison, la méthode de génération n'est pas importante mais une source vérifiable l'est. Cela a l'effet que vous rencontrez: que WS2k12 ne fait pas confiance à un certificat simplement parce qu'il porte le nom $ Random_issuing_authority, il doit pouvoir vérifier le certificat.

J'ai eu le même problème, il s'est avéré que ma solution était de mettre à jour les fichiers .crt et .key pour le serveur de messagerie tels qu'utilisés par dovecot. Exim4 sur le courrier avait un jeu de certificats / clés mis à jour, mais dovecot pointait toujours vers l'ancien jeu de certificats / clés.

L'ancienne paire de certificats / clés fonctionnait bien dans la plupart des situations, mais pas avec outlook.com ni avec MS Outlook 2013.

Des problèmes avec outlook.com m'ont amené à mettre à niveau le certificat exim4 récemment - maintenant dovecot [et le serveur de messagerie Web] utilisent également les nouveaux fichiers cert (et clé). Le serveur de messagerie lui-même a également été récemment mis à niveau [de l'ancien Debian squeeze-lts à Wheezy], l'ancienne configuration convenait parfaitement avec l'ancien jeu de certificats / clés, mais après la mise à niveau, je devais créer le nouveau jeu de certificats / clés avant Les produits MS fonctionneraient correctement avec le serveur de messagerie.

Je pense que le problème est de savoir comment avez-vous accédé aux ressources. Pour votre réseau local, vous pouvez utiliser le nom d'hôte au lieu du nom de domaine complet. Cependant, votre certificat est émis contre le nom de domaine complet.

Installez le certificat auprès des autorités de certification racines de confiance et des éditeurs approuvés.