Faire confiance à une autorité de certification non digne de confiance - Puis-je limiter la façon dont le système lui fait confiance?

(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.

ssl-certificate certificate-authority x509

— Dai
source

Au moins sous Linux, de nombreuses applications disposent d'une option permettant de spécifier l'emplacement des certificats d'autorité de certification homologue. Vous pouvez donc limiter la portée de cette autorité de certification à l'application qui l'utilise. La réponse de @CryptoGuy fonctionnerait également sous Linux, elle n’a rien de spécifique à Windows.

— Edheldil

@Edheldil: Cependant, cela dépend de l'implémentation. Par exemple, Windows a pris en charge les contraintes de nom X.509 beaucoup plus longtemps que NSS ou GnuTLS.

— Grawity

Votre système se connecte à ce service tiers; le code client de votre système peut-il être configuré pour faire confiance à l'autorité de certification de ce service, de manière à ce que cela soit fait uniquement pour ce code client , et non pour l'ensemble de votre système?

— Castaglia

@ Castilla Je peux écrire mon propre code de vérification de certificat qui fonctionne indépendamment du système hôte, mais il existe d'autres logiciels client sur lesquels je n'ai aucun contrôle et qui utilisent des services de certificats à l'échelle du système.

— Dai

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.

— Crypt32
source