ca md too weak: heruitreik van die sertifikaat of die vlak verlaag?

'n OpenVPN-kliënt wat verlede maand gewerk het, misluk nou tydens die opstart met ca md too weak, en die profiel op skyf is byte vir byte dieselfde as die een wat gewerk het. Die boodskap gaan oor die handtekening op 'n sertifikaatowerheid se sertifikaat, nie oor die data-syfer, die auth-digest of die rekeningwagwoord nie. Drie voorwaardes bepaal of die oplossing nuwe identiteitsmateriaal, 'n nuwe ketting of 'n doelbewuste beleidsverandering is. Werk dit in volgorde deur, en jy vermy die gewone uitkoms waar die tonnel terugkom deur elke TLS-verbinding op die gasheer te verswak.

Wat die fout eintlik aandui

OpenSSL lewer hierdie verifieerfout terwyl dit 'n ketting bou, wanneer die sertifikaat wat as 'n CA optree, 'n handtekening-digest dra wat die biblioteek se sekuriteitsvlak nie meer aanvaar nie. MD5 word op die verstekvlak geweier, en SHA-1 word geweier sodra die vlak verhoog word. Die digest op die bladsertifikaat maak hier minder saak as die digest op die uitreiker wat dit onderteken. Dieselfde beleid kan 'n wortel weier wat op die dag van uitreiking heeltemal gewoon was.

Daarom doen die wysiging van auth of data-ciphers niks vir hierdie fout nie. Daardie instellings bepaal hoe pakkette ná die handshake beskerm word, terwyl die verwerpte objek 'n identiteitsdokument is wat ondersoek word voordat 'n tonnel bestaan. 'n Sertifikaat kan gerieflik binne sy geldigheidsvenster sit en steeds 'n handtekening dra wat die biblioteek nie sal aanvaar nie.

Hou die kontroles apart in jou kop, en die fout hou op om geheimsinnig te lyk. Geldigheidsdatums, sleutelgebruik en handtekening-digest is onafhanklike toetse, en presies een van hulle het pas misluk.

Voorwaarde een: is die verwerpte objek die wortel?

Druk elke sertifikaat in die profiel af en lees die subject- en issuer-velde. 'n Selfondertekende wortel wys dieselfde waarde in albei, en sy handtekeningalgoritme is die een waarop die hele ketting rus. Wanneer die swak digest daar sit, erf elke blaar daaronder die probleem. Skryf die algoritme langs die subject neer sodat die latere vergelyking meganies eerder as uit die geheue gedoen word.

Saamgevoegde CA-lêers hou dikwels verskeie blokke, so identifiseer die blok wat werklik gelaai word eerder as om aan te neem die eerste een is skuldig. Die opdrag openssl x509 -in ca.pem -noout -subject -issuer -text beskryf een sertifikaat op 'n slag, wat beteken die bundel moet eers gesplit word as dit meer bevat. Vergelyk die afgedrukte handtekeningalgoritme met die digest wat jy sou verwag uit die era waarin die wortel geskep is.

'n Blaar wat met SHA-256 onder 'n swak wortel onderteken is, misluk steeds, want die kettingkontrole loop heeltemal op. Dit is dié volgorde wat die volgende voorwaarde laat saak maak.

Voorwaarde twee: beheer jy die uitreiker?

As die wortel aan jou organisasie behoort, is die duursame oplossing 'n nuwe wortel met 'n moderne digest plus heruitgereikte blare, gelewer as een profielopdatering. Dit kos 'n onderhoudsvenster en 'n plan vir toestelle wat nie dieselfde dag kan opdateer nie.

As 'n derde party die ketting uitgereik het, is die oplossing 'n versoek aan daardie operateur, en die enigste nuttige plaaslike aksie is om op te hou om op die ou materiaal te staatmaak. Die wysiging van die PEM-teks of her-save van die lêer verander niks wat die handtekening dek nie.

Een tussenliggende geval verdien 'n naam: 'n interne wortel wat ouer as die huidige verstekke is maar steeds materiaal onderteken wat ander stelsels vertrou. Om dit te vervang beteken om elke verbruiker te oudit, insluitend toestelle wat die ou sertifikaat per vingerafdruk vaspen. Tel daardie verbruikers voordat jy die verandering beplan, want 'n wortelruil wat een mis, ruil 'n opstartfout vir 'n onderbreking.

Voorwaarde drie: wat die verlaging van die vlak ook aanvaar

Die verlaging van die sekuriteitsvlak, of die keuse van OpenVPN se legacy-sertifikaatprofiel, laat die kliënt die ou digest weer aanvaar. Dit verslap ook ander kontroles in dieselfde biblioteek, vir elke verbinding wat daardie proses maak.

Dit kan verdedigbaar wees in 'n laboratorium, of as 'n kort oorbrugging terwyl vervangingsmateriaal voorberei word, solank die uitsondering tot een profiel beperk is en 'n einddatum het. As 'n permanente instelling op 'n gedeelde gasheer verbreed dit stilletjies wat elke TLS-kliënt daar sal vertrou.

Skryf die uitsondering neer met 'n eienaar en 'n verwyderingstap. 'n Ongedokumenteerde vlakverandering is ses maande later nie van 'n fout te onderskei nie, en die volgende ingenieur sal nie weet dit was ooit 'n besluit nie.

Die besluit, as 'n reël geskryf

Vervang die ketting wanneer jy die uitreiker beheer en sy verbruikers kan oplaai. Eskaleer na die uitreiker wanneer jy dit nie doen nie. Verlaag die vlak slegs as 'n gedateerde, beperkte uitsondering met die vervanging reeds geskeduleer. Enigiets anders laat dieselfde sertifikaat in plek en skuif die risiko na iets minder sigbaar.

Toets die profiel dan weer van 'n skoon kliënt, bevestig die handshake voltooi, en hou die presiese verwerpingsteks as dit steeds misluk. 'n Presiese foutboodskap is die goedkoopste ding wat jy aan wie ook al die volgende laag besit, kan gee.