(Publié sur ServerFault au lieu de StackOverflow car j’estime que cela concerne plus la configuration du système d’exploitation que le code de programmation).
Je suis actuellement responsable de la maintenance d'un système qui se connecte à un service Web tiers. Ce service Web nécessite des certificats d'authentification client, ce qui est assez juste, mais il est lui-même sécurisé avec un certificat auto-signé créé par un certificat d'autorité de certification racine créé par l'utilisateur, la même racine que celle qui crée les certificats d'authentification client.
Il suffirait simplement d'ajouter le certificat de service actuel à la liste de confiance connue et d'ignorer le certificat d'autorité créé par l'utilisateur. Malheureusement, le certificat de service change régulièrement. Le certificat d'autorité doit donc être approuvé pour que l'application ne se casse pas lorsque le service cert est renouvelé.
Cependant, je ne fais pas confiance (personnellement) au cert. De certification basé sur mon expérience avec la société exploitant le service Web - cela ne me surprendrait pas si elle serait divulguée sur le Web - et, inquiétant, la certi cela (bien que les attaques MITM externes soient une possibilité, bien qu’elles soient distantes, par exemple, je crains davantage la fuite d’un certificat utilisé pour la signature de code).
Est-il possible pour moi de dire à mon ordinateur (actuellement un serveur, mais dans les futurs clients de bureau ordinaires) de faire confiance à une autorité de certification, mais uniquement pour un ensemble donné d'utilisations de clé et un petit ensemble de noms de sujets possibles (noms de domaine )?
Le serveur est actuellement Windows Server 2012 R2, mais il pourrait être exécuté sur une machine Linux - bien que les ordinateurs de bureau soient tous des machines Windows.
Réponses:
Oui c'est possible. Dans le cas de Windows, il existe une fonctionnalité appelée Certification croisée ou Subordination qualifiée.
L'idée est de signer le certificat de l'autorité de certification émettrice tierce dans votre environnement. En conséquence, le certificat SSL distant est chaîné à votre propre certificat d'autorité de certification racine. Afin de vous protéger contre d'éventuels certificats non autorisés, vous implémentez une
Name Constraintsextension de certificat dans laquelle vous spécifiez une liste de noms acceptables. Si un certificat émis par une autorité de certification tierce pour tout autre nom (non explicitement spécifié dans l'extension Name Constraints), il sera automatiquement rejeté par votre fournisseur CryptoAPI.Outre les contraintes de nom, vous pouvez décrire la contrainte Usages de clés améliorées en définissant l'
Application Policiesextension du certificat dans le certificat croisé. Votre fournisseur de confiance ne pourra donc valider que les utilisations spécifiées dans l'Application Policiesextension.Informations complémentaires : Planification et implémentation de la certification croisée et de la subordination qualifiée à l'aide de Windows Server 2003
ps bien que l'article soit écrit sur Windows Server 2003, il s'applique toujours à la version la plus récente de Windows Server.
la source