OpenVPN asiakas, joka toimi viime kuussa, epäonnistuu nyt käynnistyksessä virheellä ca md too weak, ja levyllä oleva profiili on tavu tavulta sama, joka toimi. Viesti koskee sertifiointiviranomaisen sertifikaatin allekirjoitusta, ei datasalausmenetelmää, auth-tiivistettä tai tilin salasanaa. Kolme ehtoa ratkaisee, onko korjaus uutta identiteettimateriaalia, uusi ketju vai tarkoituksellinen politiikan muutos. Käy ne järjestyksessä läpi, niin vältät tavanomaisen lopputuloksen, jossa tunneli palaa heikentämällä jokaisen isäntäkoneen TLS-yhteyden.

Mitä virhe oikeastaan nimeää

OpenSSL nostaa tämän varmennusvirheen ketjua rakentaessaan, kun CA:na toimiva sertifikaatti kantaa allekirjoituksen tiivistettä, jota kirjaston suojaustaso ei enää hyväksy. MD5 hylätään oletustasolla ja SHA-1 hylätään, kun tasoa nostetaan. Päätesertifikaatin tiiviste merkitsee tässä vähemmän kuin sen allekirjoittavan myöntäjän tiiviste. Sama politiikka voi hylätä juuren, joka oli myöntöpäivänään täysin tavallinen.

Siksi auth tai data-ciphers muokkaaminen ei tee tälle virheelle mitään. Ne asetukset säätelevät, miten paketit suojataan kättelyn jälkeen, kun taas hylätty objekti on identiteettiasiakirja, joka tutkitaan ennen kuin tunnelia on olemassa. Sertifikaatti voi istua mukavasti voimassaolonsa sisällä ja kantaa silti allekirjoituksen, jota kirjasto ei hyväksy.

Pidä tarkistukset erillään päässäsi, niin virhe lakkaa vaikuttamasta arvoitukselliselta. Voimassaolopäivät, avaimen käyttö ja allekirjoituksen tiiviste ovat riippumattomia testejä, ja täsmälleen yksi niistä juuri epäonnistui.

Ehto yksi: onko hylätty objekti juuri?

Tulosta jokainen profiilin sertifikaatti ja lue kentät subject ja issuer. Itseallekirjoitettu juuri näyttää molemmissa saman arvon, ja sen allekirjoitusalgoritmi on se, jonka varassa koko ketju on. Kun heikko tiiviste on siellä, jokainen sen alla oleva lehti perii ongelman. Kirjoita algoritmi subjectin viereen, jotta myöhempi vertailu on mekaanista eikä muistinvaraista.

Yhdistetyt CA-tiedostot sisältävät usein useita lohkoja, joten tunnista lohko, joka todella ladataan, sen sijaan että olettaisit ensimmäisen olevan syyllinen. Komento openssl x509 -in ca.pem -noout -subject -issuer -text kuvaa yhden sertifikaatin kerrallaan, eli nippu on jaettava ensin, jos siinä on useampia. Vertaa tulostettua allekirjoitusalgoritmia tiivisteeseen, jota odottaisit juuren syntyajalta.

Heikon juuren alla SHA-256:lla allekirjoitettu lehti epäonnistuu silti, koska ketjutarkistus kulkee aivan ylös asti. Juuri tämä järjestys tekee seuraavasta ehdosta tärkeän.

Ehto kaksi: hallitsetko myöntäjää?

Jos juuri kuuluu organisaatiollesi, kestävä korjaus on uusi juuri nykyaikaisella tiivisteellä sekä uudistetut lehdet, toimitettuna yhtenä profiilipäivityksenä. Se maksaa huoltokatkon ja suunnitelman laitteille, jotka eivät voi ottaa päivitystä samana päivänä.

Jos kolmas osapuoli myönsi ketjun, korjaus on pyyntö sille operaattorille, ja ainoa hyödyllinen paikallinen toimi on lakkauttaa vanhaan materiaaliin nojaaminen. PEM-tekstin muokkaaminen tai tiedoston uudelleen tallentaminen ei muuta mitään siitä, minkä allekirjoitus kattaa.

Yksi välikuva ansaitsee nimen: sisäinen juuri, joka on vanhempi kuin nykyiset oletukset mutta allekirjoittaa yhä materiaalia, johon muut järjestelmät luottavat. Sen korvaaminen tarkoittaa jokaisen käyttäjän auditointia, myös laitteiden, jotka kiinnittävät vanhan sertifikaatin sormenjäljellä. Laske ne käyttäjät ennen muutoksen aikatauluttamista, sillä juuren vaihto, joka unohtaa yhden, vaihtaa käynnistysvirheen katkokseen.

Ehto kolme: mitä tason laskeminen vielä hyväksyy

Suojaustason laskeminen tai OpenVPN:n vanhan sertifikaattiprofiilin valitseminen saa asiakkaan hyväksymään vanhan tiivisteen jälleen. Se myös löysentää muita saman kirjaston tarkistuksia, jokaiselle yhteydelle, jonka se prosessi tekee.

Se voi olla perusteltua laboratoriossa tai lyhyenä siltana, kunnes korvaava materiaali on valmiina, kunhan poikkeus rajataan yhteen profiiliin ja siihen liittyy päättymispäivä. Pysyvänä asetuksena jaetulla isäntäkoneella se laajentaa hiljaa sitä, mitä jokainen siellä oleva TLS-asiakas luottaa.

Kirjoita poikkeus muistiin omistajan ja poistovaiheen kanssa. Dokumentoimaton tason muutos on puolen vuoden kuluttua mahdoton erottaa virheestä, eikä seuraava insinööri tiedä, että se oli koskaan päätös.

Päätös, säännöksi kirjoitettuna

Korvaa ketju, kun hallitset myöntäjää ja pystyt luettelemaan sen käyttäjät. Eskaloi myöntäjälle, kun et pysty. Laske tasoa vain päivättynä, rajattuna poikkeuksena, jonka korvaaminen on jo aikataulutettu. Mikä tahansa muu jättää saman sertifikaatin paikoilleen ja siirtää riskin vähemmän näkyvään paikkaan.

Testaa profiili sitten uudelleen puhtaasta asiakkaasta, varmista että kättely etenee loppuun, ja säilytä tarkka hylkäysteksti, jos se epäonnistuu yhä. Tarkka virheilmoitus on halvin asia, jonka voit antaa seuraavan kerroksen omistajalle.

Aiheeseen liittyvät artikkelit