ASP.NET C# - Client e server non possono comunicare perché non dispongono di un algoritmo comune - Come Risolvere

Se siete capitati su questa pagina è probabile che, a seguito della pubblicazione di una applicazione web su un server web con IIS, vi siate imbattuti nel seguente messaggio di errore ASP.NET:

System.ComponentModel.Win32Exception: Client e server non possono comunicare perché non dispongono di un algoritmo comune.

 

System.ComponentModel.Win32Exception: The client and server cannot communicate, because they do not possess a common algorithm.

Questo tipo di errore è solitamente dovuto all'implementazione non corretta (o non completa) di un protocollo di crittografia, nella maggior parte dei casi il Transport Layer Security (TLS) 1.2, e della conseguente esclusione delle precedenti versioni (TLS 1.0 e TLS 1.1): il problema può essere legato a una errata configurazione del vostro server, del client che utilizzate per connettervi ad esso oppure a una connessione server-to-server - ad es. un WebService - tra due server gestiti direttamente da voi o tra il vostro server e un servizio esterno.

Si tratta di un problema che nelle ultime settimane è diventato quantomai comune, viste le nuove linee-guida pubblicate dal PCI SSC (Payment Card Industry Security Standard Council) e destinate a entrare in vigore a partire dal 30 giugno 2018, in conseguenza dell'introduzione preliminare del PCI Data Security Standard v3.2.1 (PCI-DSS 3.2.1): in conseguenza di questo aggiornamento, tutti i protocolli di cifratura considerati non sicuri (SSL 1, SSL 2, SSL 3 e TLS 1.0) saranno progressivamente abbandonati in quanto considerati non più sicuri, lasciando spazio soltanto al TLS 1.1 e al TLS 1.2 - quest'ultimo fortemente raccomandato in quanto considerevolmente più sicuro del suo predecessore.

Per maggiori informazioni sui protocolli di crittografia e sul loro livello di sicurezza, vi consigliamo di dare un'occhiata al documento Transport Layer Protection Cheat Sheet realizzato dal progetto OWASP (Open Web Application Security Project), la principale organizzazione che si occupa a livello mondiale dello studio dei criteri di sicurezza per il World-Wide Web. In questo articolo, invece, cercheremo di comprendere come mai questo errore di "mancanza di algoritmo comune" si verifica su IIS / ASP.NET e come risolverlo.

#1: Impostare il SecurityProtocol

La prima cosa da fare è aggiungere la seguente riga di codice all'interno della nostra applicazione ASP.NET:

Nel caso in cui la versione di ASP.NET utilizzata fosse inferiore alla versione 4.5, sarà necessario impostare manualmente il numero corrispondente al TLS 1.2 nel seguente modo:

Il punto migliore per inserire questa istruzione è, probabilmente, all'interno del metodo Application_Start()  presente nel Global.asax (ASP.NET 4.x) o Startup.cs (ASP.NET 5 / .NET Core), a seconda della versione di ASP.NET utilizzata:

Inutile dire che, nel caso di una connessione server-to-server, dovrete impostare la proprietà SecurityProtocol su entrambi gli applicativi ASP.NET che effettuano la connessione - il caller e il receiver.

Un approccio più conservativo

E' importante comprendere che, aggiungendo questa riga di codice, disattiverete automaticamente il supporto di ogni altro SecurityProtocol: questo significa che SSL1, SSL2, SSL3, TLS1.0 e TLS1.1 smetteranno di funzionare, così come eventuali protocolli che saranno implementati in futuro (TLS 1.3, TLS 2.0 e così via). Per questo motivo, se vi interessa mantenere la forward-compatibility del vostro progetto con eventuali future versioni di ASP.NET e/o del protocollo TLS e/o di altri protocolli futuri, consigliamo di implementare un approccio leggermente più complesso del precedente ma certamente più corretto:

#2: Installare il .NET Framework 4.6.2+

Se impostare la proprietà SecurityProtocol non risolve il vostro problema, la cosa successiva da fare è installare una versione del .NET Framework che garantisca un supporto nativo del TLS 1.2 - ovvero dalla 4.6.2 in su - o meglio ancora, come consiglia Microsoft nell'articolo "Transport Layer Security (TLS) best practices with the .NET Framework", dalla 4.7 in su.

Nel caso in cui non abbiate possibilità di effettuare questo upgrade, potete installare le apposite hot patch (KB3154518, KB3154519, KB3154520 o KB3156421) e/o questo pacchetto di estensioni, valide dal .NET Framework 3.5 SP1 al .NET Framework 4.5.

In tutti questi casi, è però fondamentale avere un sistema operativo Windows 7 o superiore (nel caso dei sistemi Desktop) o Windows Server 2008 o superiore (nel caso dei sistemi Server): Windows XP, Windows Vista e Windows Server 2003 non sono infatti supportati - non a caso, su ciascuno di questi sistemi operativi non è possibile installare versioni di .NET Framework superiori alla 4.6.1.

#3: Impostare il .NET Framework nel Web.Config

Nel caso in cui i punti 1 e 2 non siano stati sufficienti a risolvere il problema, la causa potrebbe dipendere dal fatto che IIS non utilizza la corretta versione del .NET Framework per la vostra applicazione web. Questo può capitare in tutti i casi in cui sul server coesistono più versioni del framework installate - ad esempio, la 2.x, la 3.x, la 4.5 e/o la 4.6.x. Per risolvere questo tipo di ambiguità è opportuno specificare la versione del .NET Framework da utilizzare direttamente nel Web.Config, nel seguente modo:

L'attributo "targetFramework" istruisce IIS su quale versione del .NET Framework utilizzare per avviare l'applicazione: inutile dire che dovete assicurarvi di specificare una versione che sia installata e che supporti il TLS 1.2 in modo nativo, come la 4.6.2 o - meglio ancora - la 4.7.

Sfortunatamente, come abbiamo spiegato nel paragrafo precedente, non è possibile utilizzare questo workaround con Windows Vista, Windows XP e Windows Server 2003, poiché le versioni 4.6.2 e 4.7.x (e superiori) non possono essere installate.

#4: Modificare le chiavi di Registro di Windows

Se nessuna delle opzioni di cui sopra ha funzionato, non vi resta che provare ad alterare le chiavi di registro di Windows per "sbloccare" il supporto del TLS 1.2 (e/o di altri protocolli di crittografia) utilizzando lo script presente in questa risposta su StackOverflow, che per comodità riportiamo anche qui di seguito:

Prima di lanciarlo, assicuratevi di abilitare o disabilitare i protocolli desiderati impostando il relativo valore rispettivamente a dword:00000001  o a dword:00000000 .

Per il momento è tutto: spero che questo articolo possa essere d'aiuto ai tanti sviluppatori che si scontreranno con questo problema!