Meilleures pratiques pour l'utilisation de ServerCertificateValidationCallback

Je suis en train de travailler sur un projet qui utilise certains HTTP communication entre les deux serveurs back-end. Les serveurs sont à l'aide de certificats X509 pour l'authentification. Inutile de dire que, quand Un serveur (client) établit une connexion vers le serveur B (serveur), il y a un SSL/TLS erreur de validation, puisque les certificats utilisés ne sont pas de confiance 3ème partie de l'autorité.

Normalement, la façon de le gérer est à l'aide de ServicePointManager.ServerCertificateValidationCallbacktels que:

ServicePointManager.ServerCertificateValidationCallback += 
        (sender, cert, chain, error) =>
{
    return cert.GetCertHashString() == "xxxxxxxxxxxxxxxx";
};

Que l'approche fonctionne, sauf que c'est pas l'idéal. Ce qu'il fait essentiellement est de remplacer procédure de validation pour CHAQUE requête http effectué par l'application. Donc, si une autre classe essayez d'exécuter la requête HTTP, il échouera. Aussi, si une autre classe remplace ServicePointManager.ServerCertificateValidationCallback pour ses propres fins, puis ma communication commence à défaut d'un coup.

La seule solution qui me vient à l'esprit, est de créer un Domaine d'application client pour effectuer des requêtes HTTP. Qui serait à l'œuvre, mais, en réalité - c'est ridicule d'avoir à le faire qu'en sorte que l'on peut effectuer des requêtes HTTP. Les frais généraux sont ahurissants.

Avec cela à l'esprit, quelqu'un fait des recherches si il y a une meilleure pratique .NET, qui permettrait d'accéder aux services web, alors que la manipulation de client SSL/TLS validation sans affecter les autres clients web?

source d'informationauteur galets

  1. 21

    Acceptable (safe) méthodologie de travail .NET 4.5+ est à utiliser HttpWebRequest.ServerCertificateValidationCallback. L'affectation que de rappel sur une instance spécifique de demande de changement de la logique de validation juste pour la demande, n'influent pas sur les autres demandes.

    var request = (HttpWebRequest)WebRequest.Create("https://...");
request.ServerCertificateValidationCallback += 
        (sender, cert, chain, error) =>
{
    return cert.GetCertHashString() == "xxxxxxxxxxxxxxxx";
};
  2. 6

    Une alternative pour le code qui n'utilise pas HttpWebRequest, et pour les environnements où vous ne pouvez pas installer de confiance des certificats dans le magasin de certificats: Vérifiez que la fonction de rappel du paramètre d'erreur, qui contient toutes les erreurs qui ont été détectés avant le rappel. De cette façon, vous pouvez ignorer les erreurs spécifiques de hachage chaînes, mais encore accepter d'autres certificats de validation.

    ServicePointManager.ServerCertificateValidationCallback += 
    (sender, cert, chain, error) =>
{
    if (cert.GetCertHashString() == "xxxxxxxxxxxxxxxx")
    {
        return true;
    }
    else
    {
       return error == SslPolicyErrors.None;
    }
};

    De référence:
    https://msdn.microsoft.com/en-us/library/system.net.security.remotecertificatevalidationcallback(v=vs. 110).aspx

    Noter que ce sera encore une incidence sur les autres client web instances dans le même domaine d'application (ils vont tous accepter le spécifiée chaîne de hachage), mais au moins de ne pas bloquer les autres certificats.

  3. 5

    La simple approche pour ce scénario doit être installer les deux auto-généré les certificats de la racine de confiance magasins sur les machines client. Vous obtiendrez un avertissement de sécurité lorsque vous faites cela parce que les certificats ne peuvent pas être authentifiés par Thawte ou similaire, mais après que la pratique régulière de sécuriser la communication devrait fonctionner. IIRC, vous devez installer le plein (à la fois publique et clé privée) de la version en racine de confiance pour que cela fonctionne.