web-dev-qa-db-fra.com

Le client et le serveur ne peuvent pas communiquer car ils ne possèdent pas d'algorithme commun sur Windows Server 2008 Web.

Je travaille sur une application ASP.Net WebForms. Nous utilisons l'API de démarrage de PayFort pour le processus de paiement. L'application fonctionne correctement sur notre ordinateur local (Windows 10), mais le message d'erreur suivant s'affiche lorsque nous essayons d'effectuer un paiement à l'aide de leur API sur notre serveur de déploiement (Windows Server Web 2008). 

Le client et le serveur ne peuvent pas communiquer car ils ne possèdent pas D'algorithme commun.

La documentation sur leur page Web ( PayFort Start et SSL/TLS ) indique qu'ils utilisent Tls1.2 pour la communication. Leur API contient déjà le code pour utiliser Tls1.2 comme protocole de sécurité

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Nous avons construit l'application sur .Net Framework 4.5 depuis Tls1.2 uniquement pris en charge par .Net 4.5 ou une version ultérieure. Il va sans dire que .Net Framework 4.5 est installé sur notre serveur. 

Nous avons également ajouté les valeurs de registre pour Tls1.1 et Tls1.2 dans le registre Windows.

En utilisant l’outil SSL Labs , nous avons également confirmé qu’au moins deux suites de chiffrement étaient prises en charge par les deux serveurs (notre serveur et le serveur d’API de PayFort) ( https: //api.start. payfort.com ) 

Suites de chiffrement prises en charge par le serveur API de PayFort  Cipher suites supported by PayFort's API Server (Les verts sont ceux qui sont communs avec notre serveur) 

Suites de chiffrement supportées par notre serveur  Cipher Suites supported by our server

J'ai également utilisé le Nartac IIS logiciel de cryptographie et les informations suivantes sont affichées sous la forme Best Practices Nartac IIS crypto details

Je ne sais pas si cela a quelque chose à voir avec le problème, mais voici les détails du certificat SSL installé sur notre serveur. 
 SSL certificate details

Quelqu'un peut-il indiquer que nous agissons mal et que devons-nous faire pour communiquer avec le serveur souhaité et effectuer le paiement à partir de l'application déployée sur notre serveur, comme nous le faisons parfaitement sur notre machine locale.

c#asp.netsslwindows-server-2008tls1.2
6
sohaiby

Le problème était le système d'exploitation. Nous utilisions Windows Server 2008 et nous n’avions pas réalisé que le protocole du système d’exploitation de l’application avait besoin de communiquer avec un autre serveur. Puisque .NET Framework 4.5 est installé et que nous utilisons également le code ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12; pour forcer l’application à utiliser Tls1.2 (selon les besoins), nous sommes donc convaincus que tout devrait fonctionner correctement, mais cela ne se produira évidemment pas. 
tl; dr; Nous avons installé Windows Server 2012 sur la machine et l'application fonctionne correctement (comme il se doit)

1
sohaiby

Je suis avec l'équipe Payfort Start. Nous avons une page ici qui aide à décrire ce problème plus en détail. Essentiellement, votre client API (la bibliothèque que vous utilisez pour effectuer la demande HTTPS) doit prendre en charge TLS1.2. L'API de démarrage rejettera toute demande qui ne prend pas au minimum en charge TLS1.2.

Il semblerait que WebRequest prenne en charge TLS 1.1 et 1.2, mais vous devez les activer manuellement. Vous pouvez vous référer à cette réponse pour le correctif.

Pour vérifier que votre client prend en charge TLS1.2 , vous pouvez envoyer une demande GET de votre application à https://www.howsmyssl.com/a/check et lire la réponse.

En cURL:

> curl -X GET https://www.howsmyssl.com/a/check

Résultats:

{
  given_cipher_suites: [
    "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_RSA_WITH_AES_128_GCM_SHA256",
    "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_256_CBC_SHA",
    "TLS_RSA_WITH_AES_256_CBC_SHA",
    "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
    "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
    "TLS_ECDHE_RSA_WITH_RC4_128_SHA",
    "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA",
    "TLS_DHE_RSA_WITH_AES_128_CBC_SHA",
    "TLS_DHE_DSS_WITH_AES_128_CBC_SHA",
    "TLS_RSA_WITH_RC4_128_SHA",
    "TLS_RSA_WITH_RC4_128_MD5",
    "TLS_RSA_WITH_AES_128_CBC_SHA",
    "TLS_RSA_WITH_3DES_EDE_CBC_SHA",
    "TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"
  ],
  ephemeral_keys_supported: true,
  session_ticket_supported: true,
  tls_compression_supported: false,
  unknown_cipher_suite_supported: false,
  beast_vuln: false,
  able_to_detect_n_minus_one_splitting: false,
  insecure_cipher_suites: {
    "TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA": [
      "uses keys smaller than 128 bits in its encryption"
    ]
  },
  tls_version: "TLS 1.2",
  rating: "Bad"
}

Cherchez le tls_version à la fin.

1
FloatingRock

J'espère que cela peut clarifier un peu votre situation et aider:

1 Confirmez que l'application est exécutée sous .net 4.5 (ou supérieur).

TLS 1.2 est pris en charge dans la version 4.5+. Pour obtenir la version actuelle du framework .net sous lequel vous utilisez l'application: https://msdn.Microsoft.com/en-us/library/system.environment.version(v=vs.110).aspx

2 Activer TLS 1.2 dans le registre Windows.

Je viens de trouver ce lien utile pour activer TLS 1.2 Le client et le serveur ne peuvent pas communiquer car ils ne possèdent pas un algorithme commun

1
Gabriel Pavel