ca md too weak: reemitem certificatul sau coborâm nivelul?

OpenVPN client care funcționa luna trecută acum eșuează la pornire cu ca md too weak, iar profilul de pe disc este identic byte cu byte cu cel care funcționa. Mesajul privește semnătura de pe certificatul unei autorități de certificare, nu cifrul de date, digestul auth sau parola contului. Trei condiții decid dacă remedierea este material nou de identitate, un lanț nou sau o schimbare deliberată de politică. Parcurge-le în ordine și eviți rezultatul obișnuit în care tunelul revine slăbind fiecare conexiune TLS de pe gazdă.

Ce numește de fapt eroarea

OpenSSL ridică această eroare de verificare în timp ce construiește un lanț, când certificatul care acționează ca CA poartă un digest de semnătură pe care nivelul de securitate al bibliotecii nu îl mai acceptă. MD5 este refuzat la nivelul implicit, iar SHA-1 este refuzat odată ce nivelul este ridicat. Digestul de pe certificatul frunză contează aici mai puțin decât digestul emitentului care îl semnează. Aceeași politică poate refuza o rădăcină care era perfect obișnuită în ziua în care a fost emisă.

De aceea editarea auth sau data-ciphers nu face nimic pentru această defecțiune. Acele setări guvernează modul în care pachetele sunt protejate după handshake, în timp ce obiectul refuzat este un document de identitate examinat înainte să existe un tunel. Un certificat poate sta confortabil în fereastra sa de valabilitate și totuși purta o semnătură pe care biblioteca nu o va accepta.

Ține verificările separate în minte și eroarea încetează să mai pară misterioasă. Datele de valabilitate, utilizarea cheii și digestul semnăturii sunt teste independente, iar exact unul dintre ele tocmai a eșuat.

Prima condiție: obiectul refuzat este rădăcina?

Tipărește fiecare certificat din profil și citește câmpurile subject și issuer. O rădăcină auto-semnată arată aceeași valoare în ambele, iar algoritmul ei de semnătură este cel pe care se sprijină întregul lanț. Când digestul slab stă acolo, fiecare frunză de sub el moștenește problema. Scrie algoritmul lângă subject ca comparația ulterioară să fie mecanică, nu din memorie.

Fișierele CA combinate conțin adesea mai multe blocuri, așa că identifică blocul care este chiar încărcat în loc să presupui că primul este vinovat. Comanda openssl x509 -in ca.pem -noout -subject -issuer -text descrie un singur certificat o dată, ceea ce înseamnă că pachetul trebuie împărțit mai întâi dacă conține mai multe. Compară algoritmul de semnătură tipărit cu digestul pe care l-ai aștepta din epoca în care a fost creată rădăcina.

O frunză semnată cu SHA-256 sub o rădăcină slabă tot eșuează, pentru că verificarea lanțului urcă până sus. Această ordine este cea care face importantă condiția următoare.

A doua condiție: controlezi emitentul?

Dacă rădăcina aparține organizației tale, remedierea durabilă este o rădăcină nouă cu un digest modern plus frunze reemise, livrate ca o singură actualizare de profil. Asta costă o fereastră de mentenanță și un plan pentru dispozitivele care nu pot primi actualizarea în aceeași zi.

Dacă un terț a emis lanțul, remedierea este o cerere către acel operator, iar singura acțiune locală utilă este să nu te mai bazezi pe materialul vechi. Editarea textului PEM sau resalvarea fișierului nu schimbă nimic din ce acoperă semnătura.

Un caz intermediar merită numit: o rădăcină internă mai veche decât valorile implicite actuale, dar care semnează în continuare material în care au încredere alte sisteme. Înlocuirea ei înseamnă auditarea fiecărui consumator, inclusiv a echipamentelor care fixează certificatul vechi prin amprentă. Numără acei consumatori înainte de a programa schimbarea, pentru că o înlocuire de rădăcină care ratează unul schimbă o eroare de pornire pe o întrerupere.

A treia condiție: ce mai acceptă coborârea nivelului

Coborârea nivelului de securitate, sau selectarea profilului legacy de certificate al OpenVPN, face clientul să accepte din nou digestul vechi. De asemenea, relaxează alte verificări din aceeași bibliotecă, pentru fiecare conexiune pe care o face acel proces.

Acest lucru poate fi justificabil într-un laborator, sau ca punte scurtă cât timp se pregătește materialul de înlocuire, atât timp cât excepția este limitată la un profil și are o dată de sfârșit. Ca setare permanentă pe o gazdă partajată, lărgește în tăcere ceea în ce va avea încredere fiecare client TLS de acolo.

Notează excepția cu un proprietar și un pas de eliminare. O schimbare de nivel nedocumentată nu se distinge de o greșeală șase luni mai târziu, iar următorul inginer nu va ști că a fost vreodată o decizie.

Decizia, scrisă ca regulă

Înlocuiește lanțul când controlezi emitentul și poți enumera consumatorii lui. Escaladează la emitent când nu îl controlezi. Coboară nivelul doar ca excepție datată și delimitată, cu înlocuirea deja programată. Orice altceva lasă același certificat pe loc și mută riscul undeva mai puțin vizibil.

Apoi retestează profilul dintr-un client curat, confirmă că handshake-ul se finalizează și păstrează textul exact al refuzului dacă tot eșuează. Un mesaj de eroare precis este cel mai ieftin lucru pe care îl poți da celui care deține următorul strat.