ca md too weak: muling ilabas ang sertipiko o ibaba ang antas?

OpenVPN kliyente na gumana noong nakaraang buwan ay nabibigo na ngayon sa pagsisimula gamit ang ca md too weak, at ang profile sa disk ay kaparehong-kapareho ng byte na gumana. Ang mensahe ay tungkol sa lagda sa sertipiko ng isang awtoridad ng sertipiko, hindi sa cipher ng datos, digest ng auth, o password ng account. Tatlong kundisyon ang nagpapasya kung ang pagtatama ay bagong materyal ng pagkakakilanlan, bagong chain, o sadyang pagbabago ng patakaran. Gawin sila nang sunud-sunod, at maiiwasan mo ang karaniwang kinalabasan kung saan bumabalik ang tunnel sa pamamagitan ng pagpapahina ng bawat TLS na koneksyon sa host.

Ano ang talagang pinapangalanan ng error

Itinataas ng OpenSSL ang error sa pagpapatunay na ito habang bumubuo ng chain, kapag ang sertipikong gumaganap bilang CA ay may dalang digest ng lagda na hindi na tinatanggap ng antas ng seguridad ng library. Ang MD5 ay tinatanggihan sa default na antas, at ang SHA-1 ay tinatanggihan kapag itinaas ang antas. Ang digest sa leaf certificate ay mas mababa ang kahalagahan dito kaysa sa digest ng issuer na pumipirma nito. Maaaring tanggihan ng parehong patakaran ang isang root na lubos na karaniwan noong araw na inilabas ito.

Kaya naman ang pag-edit ng auth o data-ciphers ay walang nagagawa para sa kabiguan na ito. Ang mga setting na iyon ay namamahala kung paano pinoprotektahan ang mga packet pagkatapos ng handshake, samantalang ang tinanggihang bagay ay isang dokumento ng pagkakakilanlan na sinusuri bago pa man umiral ang tunnel. Ang sertipiko ay maaaring maupo nang komportable sa loob ng window ng validity nito at may dalang lagda pa rin na hindi tatanggapin ng library.

Panatilihing hiwalay ang mga pagsusuri sa isipan at titigil ang error sa pagmumukhang misteryoso. Ang mga petsa ng validity, paggamit ng key at digest ng lagda ay magkakahiwalay na pagsubok, at eksaktong isa sa kanila ang kabibigo lang.

Unang kundisyon: ang tinanggihang bagay ba ay ang root?

I-print ang bawat sertipiko sa profile at basahin ang subject at issuer na field. Ang self-signed na root ay nagpapakita ng parehong halaga sa dalawa, at ang algorithm ng lagda nito ang pinagbabatayan ng buong chain. Kapag naroon ang mahinang digest, ang bawat leaf sa ilalim nito ay namamana ng problema. Isulat ang algorithm sa tabi ng subject upang ang susunod na paghahambing ay mekanikal at hindi mula sa memorya.

Ang pinagsamang CA na file ay madalas may ilang bloke, kaya tukuyin kung aling bloke ang talagang na-load sa halip na ipagpalagay na ang una ang may kasalanan. Ang utos na openssl x509 -in ca.pem -noout -subject -issuer -text ay naglalarawan ng isang sertipiko sa isang pagkakataon, ibig sabihin ay dapat munang hatiin ang bundle kung may higit pa. Ihambing ang naka-print na algorithm ng lagda sa digest na inaasahan mo mula sa panahong nilikha ang root.

Ang leaf na pinirmahan ng SHA-256 sa ilalim ng mahinang root ay nabibigo pa rin, dahil ang pagsusuri ng chain ay umaakyat hanggang tuktok. Ang pagkasunod-sunod na iyon ang nagpapahalaga sa susunod na kundisyon.

Ikalawang kundisyon: kontrolado mo ba ang issuer?

Kung ang root ay pag-aari ng iyong organisasyon, ang matibay na pagtatama ay bagong root na may modernong digest at mga leaf na muling inilabas, na inihahatid bilang isang update ng profile. Nagkakahalaga iyon ng maintenance window at plano para sa mga device na hindi makakakuha ng update sa parehong araw.

Kung isang third party ang naglabas ng chain, ang pagtatama ay isang kahilingan sa operator na iyon, at ang tanging kapaki-pakinabang na lokal na aksyon ay itigil ang pag-asa sa lumang materyal. Ang pag-edit ng PEM text o muling pag-save ng file ay walang binabago sa sakop ng lagda.

Isang gitnang kaso ang karapat-dapat pangalanan: isang panloob na root na mas matanda kaysa sa kasalukuyang default ngunit pumipirma pa rin ng materyal na pinagkakatiwalaan ng ibang sistema. Ang pagpapalit nito ay nangangahulugan ng pag-audit sa bawat consumer, kabilang ang mga appliance na nagpi-pin ng lumang sertipiko sa pamamagitan ng fingerprint. Bilangin ang mga consumer na iyon bago mag-iskedyul ng pagbabago, dahil ang pagpapalit ng root na may nakaligtaan ay nagpapalit ng error sa pagsisimula para sa isang outage.

Ikatlong kundisyon: ano pa ang tinatanggap ng pagbaba ng antas

Ang pagbaba ng antas ng seguridad, o pagpili ng legacy certificate profile ng OpenVPN, ay nagpapagawa sa kliyente na tanggapin muli ang lumang digest. Pinapaluwag din nito ang iba pang pagsusuri sa parehong library, para sa bawat koneksyon na ginagawa ng prosesong iyon.

Maaaring ipagtanggol iyon sa laboratoryo, o bilang maikling tulay habang inihahanda ang kapalit na materyal, hangga't ang eksepsyon ay limitado sa isang profile at may petsa ng pagtatapos. Bilang permanenteng setting sa isang shared host, tahimik nitong pinapalawak kung ano ang pagtitiwalaan ng bawat TLS client doon.

Isulat ang eksepsyon kasama ng may-ari at hakbang sa pag-alis. Ang hindi dokumentadong pagbabago ng antas ay hindi makikilala sa isang pagkakamali makalipas ang anim na buwan, at hindi malalaman ng susunod na inhinyero na minsan itong naging desisyon.

Ang desisyon, nakasulat bilang tuntunin

Palitan ang chain kapag kontrolado mo ang issuer at maaari mong ilista ang mga consumer nito. Iakyat sa issuer kapag hindi mo ito kontrolado. Ibaba ang antas lamang bilang eksepsyon na may petsa at limitado, habang ang kapalit ay naka-iskedyul na. Anupaman ang iba ay iniiwan ang parehong sertipiko sa puwesto at inililipat ang panganib sa isang lugar na hindi gaanong nakikita.

Pagkatapos ay subukan muli ang profile mula sa malinis na kliyente, tiyakin na natatapos ang handshake, at itago ang eksaktong teksto ng pagtanggi kung nabibigo pa rin ito. Ang tumpak na mensahe ng error ay ang pinakamurang bagay na maibibigay mo sa may-ari ng susunod na layer.