Depanarea problemelor de comunicare TLS / SSL la efectuarea unei solicitari web HTTP in ASP.NET Partea 3

In prima si a doua postare despre depanarea problemelor TLS / SSL, am lucrat la remedierea unui   mesaj de eroare „Conexiunea de baza a fost inchisa: nu s-a putut stabili relatia de incredere pentru canalul securizat SSL / TLS” .

In primul nostru scenariu, am facut cateva teste de baza, cum ar fi un „test de browser” si am constatat ca certificatul utilizat nu era valid.

In cel de-al doilea scenariu, am comparat o urma de retea luata dintr-un scenariu care nu reusea cu o urma luata dintr-un scenariu de succes. Am vazut ca negocierea TLS intre client si server esueaza.

Am remediat ambele probleme si stim ca versiunile TLS se potrivesc pentru client si server, iar certificatul este in regula, dar primim in continuare un mesaj de eroare.

Daca va amintiti rezultatul scenariului 2, vedeam un pachet FIN care venea de la client si serverul reseta conexiunea TCP:

De aceasta data, eroarea pe care o primim este diferita:

Eroare server in aplicatia „/”.

————————————————– ——————————

Certificatul la distanta este nevalid conform procedurii de validare.

Descriere: s-a produs o exceptie nesolutionata in timpul executarii cererii web curente. Va rugam sa examinati urmarirea stivei pentru mai multe informatii despre eroare si de unde a aparut in cod.

Detalii exceptie: System.Security.Authentication.AuthenticationException: Certificatul de la distanta este nevalid conform procedurii de validare.

Mesajul de exceptie ne spune ca certificatul la distanta nu este valid. Stim ca am trecut negocierile TLS si Cipher, deci ar trebui sa existe o alta validare care nu reuseste. Ce ar putea fi si cum putem rezolva aceasta problema?

Aici este  inregistrata inregistrarea SChannel ETL  sau  urmarirea System.Net  . Nu ne vom concentra aici asupra inregistrarii SChannel ETL, deoarece ar putea fi un alt subiect al postarii. In schimb, vom folosi urmarirea System.Net pentru a depana aceasta problema.

Un cuvant rapid despre urmarirea System.Net

O urmarire System.Net este o optiune de diagnostic disponibila in .NET Framework de la versiunea 2.0. Aceasta face parte din spatiul de nume System.Diagnostic si poate fi folosit pentru a captura detaliile claselor System.Net, inclusiv operatiunile System.Net.Socket. O puteti activa in fisierul de configurare. Un exemplu de utilizare este vazut mai jos:

<system.diagnostics> <sources> <source name = “System.Net” tracemode = “includehex” maxdatasize = “1024”> <listeners> <add name = “System.Net” /> </listeners> </source> <source name = “System.Net.Sockets”> <listeners> <add name = “System.Net” /> </listeners> </source> <source name = “System.Net.Cache”> <listeners> < add name = “System.Net” /> </listeners> </source> </sources> <switches> <add name = “System.Net” value = “Verbose” /> <add name = “System.Net. Sockets “value =” Verbose “/> <add name =” System.Net.Cache “value =” Verbose “/> </switches> <sharedListeners> <add name =” System.Net “type = “System.Diagnostics.TextWriterTraceListener” initializeData = “c: \ tracelogs \ network_trace.log” /> </sharedListeners> <trace autoflush = “true” /> </system.diagnostics>

Pentru a activa urmarirea System.Net, puteti copia pur si simplu configuratia de mai sus si lipiti-o in fisierul web.config al aplicatiei ASP.NET. Va rugam sa acordati atentie folderului in care vor fi create urmele:

<add name = “System.Net” type = “System.Diagnostics.TextWriterTraceListener”  initializeData = “c: \ tracelogs \ network_trace.log” />

Aici, in exemplul de mai sus, urmele vor fi scrise in directorul  c: \ tracelogs \  , iar identitatea grupului de aplicatii ar trebui sa aiba permisiunea de scriere in acel folder.

Odata ce am reprodus problema dupa activarea urmaririi System.Net, va fi creat un fisier jurnal in folderul pe care il specificam in configuratie. Fisierul de urmarire este „lizibil de om” si poate fi deschis in orice editor de text. Sa aruncam o privire si daca va uitati cu atentie, veti vedea urmatoarele raportate la sfarsitul urmelor:

[Cheie publica]

Algoritm:

Lungime RSA : 2048

…

…

…

Informatii System.Net: 0: [2504] SecureChannel # 26517107 – Certificatul de la distanta are erori:

Informatii System.Net: 0: [2504] SecureChannel # 26517107 –  Un lant de certificate procesat, dar terminat intr-un certificat radacina care nu este de incredere de catre furnizorul de incredere.

Informatii System.Net: 0: [2504] SecureChannel # 26517107 – Certificatul de la distanta a fost verificat ca nevalid de catre utilizator.

System.Net.Sockets Verbose: 0: [2504] Socket # 16754362 :: Dispose ()

System.Net Error: 0: [2504] Exceptie in HttpWebRequest # 46228029 :: – Conexiunea de baza a fost inchisa: Nu s-a putut stabili relatia de incredere pentru canalul securizat SSL / TLS ..

Eroare System.Net: 0: [2504] Exceptie in HttpWebRequest # 46228029 :: GetResponse – Conexiunea de baza a fost inchisa: Nu s-a putut stabili relatia de incredere pentru canalul securizat SSL / TLS …

Mesajul de eroare „ Un lant de certificate procesat, dar terminat intr-un certificat radacina care nu este de incredere de catre furnizorul de incredere ” ne spune ca exista o problema cu certificatul radacina al CA (autoritatea de certificare) si nu este de incredere, deci cel mai probabil depozitul de certificate pentru CA radacina de incredere nu contine CA radacina pentru certificatul la distanta.

Dar, amintiti-va testul browserului pe care l-am facut in primul nostru scenariu, acesta a functionat bine, astfel incat magazinul de certificate CA de radacina de incredere al utilizatorului ar trebui sa aiba CA radacina pentru certificatul de la distanta.

Sa verificam inca o data certificatul cu „browser test”: deschideti un browser pe serverul in care functioneaza aplicatia dvs. ASP.NET, rasfoiti adresa URL a punctului final (care este https://iis85.buggybits.com/ in cazul nostru) si faceti clic pe detalii despre certificat si treceti la fila „Calea de certificare”:

Dupa cum s-a vazut, certificatul provine dintr-un CA intern numit amborp-AMBDC-CA. Sa aruncam o privire la magazinul de certificate al utilizatorului. Confirmam ca certificatul radacina este deja acolo:

Dar acesta este magazinul de certificate de utilizator.  Clientul ASP.NET va utiliza magazinul „Autoritati de certificare radacina de incredere” din contul „computer local”. Daca deschidem si verificam acel magazin, vedem ca certificatul radacina al CA nu este instalat acolo. Odata ce importam certificatul radacina al CA in magazinul radacina de incredere al contului computerului, aplicatia incepe sa functioneze bine. In cele din urma!!! 

Rezumat:

• In prima noastra postare, am aflat ca certificatul trebuie sa fie unul valid. Spre deosebire de „clientii umani”, un client ASP.NET nu poate face clic pe „Ok, am incredere in acest certificat / site web” daca apare o eroare de certificat, cu exceptia cazului in care ii spuneti in mod explicit aplicatiei sa ignore erorile de certificat, ceea ce de fapt nu este o abordare recomandata .
• In a doua postare, am aflat ca negocierea TLS / Cipher este o cerinta pentru o strangere de mana SSL de succes.
• In aceasta a treia si ultima postare, am aflat cum urmarirea System.Net ar putea fi utila la depanarea problemelor legate de TLS / SSL.

Daca aveti orice comentariu sau sugestie, va rugam sa folositi sectiunea de comentarii. Daca v-ati confruntat cu o alta problema atunci cand efectuati apeluri WCF, web service sau HTTP catre un punct final SSL, va rugam sa ne anuntati si poate putem pregati o alta postare de blog pentru problema respectiva.

Depanare fericita …

–

AMB