2016-07-15 366 views
6

Eseguo un'applicazione nell'applicazione di Azure Standard: 1 Piano piccolo. Framework is 4.6.1Solo su azzurro: Impossibile creare il canale protetto SSL/TLS

Questa applicazione sta chiamando un'API protetta SSL. Il protocollo SSL è pubblicato da StartCom Class 1 DV Server CA, il mio browser locale mi dice che il certificato è valido.

Se eseguo l'applicazione sul mio computer locale, tutto funziona. Tuttavia, quando schierato all'azzurro non riesce con l'errore follwing:

System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The request was aborted: Could not create SSL/TLS secure channel.

at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult)

at System.Net.Http.HttpClientHandler.GetResponseCallback(IAsyncResult ar)

--- End of inner exception stack trace ---

at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)

at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)

Il codice:

public async Task<List<QutationOverview>> GetAll(string url, DateTime lastActionDate) 
    { 
     var result = string.Empty; 

     try 
     { 


      var userName = await _settingManager.GetSettingValueAsync("API.UserName"); 
      var password = await _settingManager.GetSettingValueAsync("API.Password"); 


      ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | 
                SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; 


      ServicePointManager 
       .ServerCertificateValidationCallback += 
       (sender, cert, chain, sslPolicyErrors) => true; 


      //Add date filter 
      //Always request qutations where the last action took place >= Yesterday 
      var requestUrl = 
       $"GetALL/?last_action_date={lastActionDate.AddDays(-1).ToString("yyyy-MM-dd")}&format=json"; 


      var baseAddress = new Uri(url); 
      var credentials = Convert.ToBase64String(Encoding.ASCII.GetBytes($"{userName}:{password}")); 

      Logger.InfoFormat("GetAllQuotationsAsync for url {0}{1}", url, requestUrl); 

      using (var httpClient = new HttpClient {BaseAddress = baseAddress}) 
      { 
       httpClient.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("Basic", credentials); 
       using (var response = await httpClient.GetAsync(requestUrl)) 
       { 
        result = await response.Content.ReadAsStringAsync(); 
        Logger.Info(result); 
       } 
      } 
     } 

     catch (Exception ex) 
     { 
      Logger.ErrorFormat("GetAllQuotationsAsync {0}: {1}", url, ex); 
     } 
     var data = JsonConvert.DeserializeObject<List<QutationOverview>>(result); 

     return data; 
    } 

Come potete vedere ho saltare la convalida del certificato e ha aggiunto i protocolli di sicurezza.

Tuttavia, la richiesta continua a non riuscire.


Ecco la risposta caputred http://textuploader.com/5ers0


Avete qualche idea di come ottenere questo lavoro su Azure?

+0

correlati: http: // StackOverflow.it/questions/34437473/could-not-create-ssl-tls-secure-channel-in-an-azure-web-application? rq = 1 –

+0

Il link textuploader.com è ora rotto. –

risposta

3

Cattura l'handshake TLS. Se manca ServerHello probabilmente non hai una suite di crittografia comune con il telecomando.

Eseguire entrambi tramite https://www.ssllabs.com/ssltest/ per verificare le suite di crittografia supportate su entrambe le estremità. Per Windows Server, le suite di crittografia possono essere abilitate o disabilitate solo a livello globale (come in nessuna distinzione tra componente client/server), ecco perché questo rende un buon test.

UPDATE: Trovato un problema lampante nel mio ragionamento, App servizio ha uno strato frontend ed è lì che TLS termina, in modo confrontando le cifre in questo modo va da nessuna parte.

Invece, eseguire

Get-TlsCipherSuite 

da PowerShell di Kudu e confrontare le cifre contro il vostro API del telecomando (le cifre di cui si può verificare sopra a https://ssllabs.com/ssltest). Dovresti avere almeno una partita.

Se nessuno corrisponde, è necessario passare a Servizi cloud o VM e abilitare almeno una delle suite di crittografia del proprio telecomando. Dover andare in questa direzione di solito significa una cosa: il tuo telecomando utilizza una crittografia debole (SSL 3.0 o TLS 1.0 con RC4) e dovresti chattare con quei cittadini o trovare nuovi cittadini che stiano scuotendo TLS 1.2.

Dalla traccia System.Net:

[8356] 00000000 : 15 03 03 00 02 

Questa è la sequenza di byte per Fatal Handshake Error, che si basa sulla mia non comune cifra teoria.

Nota il primo byte (0x15):

Record Type Values  dec  hex 
------------------------------------- 
CHANGE_CIPHER_SPEC  20  0x14 
ALERT      21  0x15 
HANDSHAKE     22  0x16 
APPLICATION_DATA   23  0x17 
+0

Grazie, ho rimosso ServicePointManager .ServerCertificateValidationCallback + = (sender, cert, chain, sslPolicyErrors) => true; e ha aggiunto ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 ;. Tuttavia, l'errore è sempre lo stesso –

+0

Hmm .. usa un 'curl' recente con' --tlsv1.x' e controlla se il telecomando supporta realmente TLS 1.2: https://curl.haxx.se/docs/manpage. html # - tlsv10. Prova ad acquisire l'handshake TLS ClientHello + ServerHello (traccia Wireshark o System.Net), inseriscilo qui, che dovrebbe aiutare a trovare la causa principale. – evilSnobu

+0

Ho allegato la risposta wirehark nel post principale. Questo aiuta? –