ca md too weak: újítsuk ki újra a tanúsítványt vagy csökkentsük a szintet?
A hiba olyan aláírás-kivonatot nevez meg, amelyet az ügyfél már elutasít, nem gyenge jelszót. Válasszon a lánc újrakiadása, a kibocsátó megkeresése vagy a házirend csökkentése között.
Egy OpenVPN-ügyfél, amely múlt hónapban még működött, most indításkor ezzel bukik el: ca md too weak, a lemezen lévő profil pedig bájtról bájtra ugyanaz, amely működött. Az üzenet egy tanúsító hatóság tanúsítványán lévő aláírásra vonatkozik, nem az adattitkosításra, az auth-kivonatra vagy a fiók jelszavára. Három feltétel dönti el, hogy a javítás új identitásanyag, új lánc vagy szándékos házirend-változás. Dolgozza fel őket sorrendben, és elkerüli azt a szokásos kimenetet, amelyben az alagút úgy tér vissza, hogy a gazdagép minden TLS-kapcsolatát gyengíti.
Mit nevez meg a hiba valójában
Az OpenSSL akkor dobja ezt az ellenőrzési hibát láncépítés közben, amikor a CA-ként működő tanúsítvány olyan aláírás-kivonatot hordoz, amelyet a könyvtár biztonsági szintje már nem fogad el. Az MD5-öt az alapértelmezett szinten utasítja el, a SHA-1-et pedig a szint emelésekor. A végponti tanúsítvány kivonata itt kevésbé számít, mint az őt aláíró kibocsátóé. Ugyanaz a házirend elutasíthat egy gyökeret, amely kibocsátásának napján teljesen szokványos volt.
Ezért a auth vagy a data-ciphers szerkesztése semmit sem tesz ezért a hibaért. Azok a beállítások azt szabályozzák, hogyan védettek a csomagok a kézfogás után, míg az elutasított objektum olyan identitás-okirat, amelyet a csatorna létrejötte előtt vizsgálnak. Egy tanúsítvány kényelmesen ülhet érvényességi ablaka belsejében, és mégis olyan aláírást hordozhat, amelyet a könyvtár nem fogad el.
Tartsa külön a fejében az ellenőrzéseket, és a hiba megszűnik rejtélyesnek látszani. Az érvényességi dátumok, a kulcshasználat és az aláírás-kivonat független vizsgálatok, és közülük pontosan egy bukott meg az imént.
Első feltétel: az elutasított objektum a gyökér?
Nyomtassa ki a profil minden tanúsítványát, és olvassa el a subject és issuer mezőket. Az önaláírt gyökér mindkettőben ugyanazt az értéket mutatja, és az ő aláírás-algoritmusán nyugszik az egész lánc. Ha a gyenge kivonat ott van, minden alatta lévő levél örökli a problémát. Írja fel az algoritmust a subject mellé, hogy a későbbi összehasonlítás gépi legyen, ne emlékezetből való.
A kötegezett CA-fájlok gyakran több blokkot tartalmaznak, ezért azonosítsa a ténylegesen betöltött blokkot ahelyett, hogy feltételezné, az első a hibás. A parancs openssl x509 -in ca.pem -noout -subject -issuer -text egyszerre egy tanúsítványt ír le, ami azt jelenti, hogy több esetén előbb fel kell darabolni a köteget. Hasonlítsa össze a kiírt aláírás-algoritmust azzal a kivonattal, amelyet a gyökér keletkezésének korából várna.
A gyenge gyökér alatt SHA-256-tal aláírt levél is elbukik, mert a lánc-ellenőrzés egészen a tetejéig halad. Ez a sorrend teszi fontossá a következő feltételt.
Második feltétel: Ön irányítja a kibocsátót?
Ha a gyökér az Ön szervezetéé, a tartós javítás egy modern kivonatú új gyökér, valamint újrakiadott levelek, egyetlen profilfrissítésként átadva. Ez karbantartási ablakot és tervet igényel azoknak az eszközöknek, amelyek nem tudják ugyanazon a napon felvenni a frissítést.
Ha a láncot harmadik fél adta ki, a javítás egy kérés ahhoz az üzemeltetőhöz, és az egyetlen hasznos helyi lépés az, hogy felhagy a régi anyagra támaszkodással. A PEM-szöveg szerkesztése vagy a fájl újramentése semmit sem változtat azon, amit az aláírás lefed.
Egy köztes eset nevet érdemel: belső gyökér, amely régebbi a mai alapértékeknél, de még mindig olyan anyagot ír alá, amelyben más rendszerek bíznak. Cseréje minden fogyasztó auditját jelenti, beleértve azokat az eszközöket, amelyek a régi tanúsítványt ujjlenyomattal rögzítik. Számolja össze ezeket a fogyasztókat a változás ütemezése előtt, mert egy gyökércsere, amely egyet kihagy, egy indítási hibát cserél le egy kiesésre.
Harmadik feltétel: mit fogad el még a szint csökkentése
A biztonsági szint csökkentése vagy az OpenVPN régi tanúsítványprofiljának kiválasztása ismét elfogadottá teszi a régi kivonatot az ügyfél számára. Emellett ugyanazon könyvtár más ellenőrzéseit is lazítja, minden kapcsolatnál, amelyet az a folyamat létrehoz.
Ez laboratóriumban védhető lehet, vagy rövid hídként, amíg a csereanyag elkészül, feltéve hogy a kivétel egyetlen profilra korlátozódik és záró dátummal rendelkezik. Állandó beállításként egy megosztott gazdagépen csendesen kiterjeszti, miben fog bízni ott minden TLS-ügyfél.
Írja le a kivételt felelőssel és eltávolítási lépéssel. A nem dokumentált szintváltozás fél év múlva nem különböztethető meg egy hibától, és a következő mérnök nem fogja tudni, hogy ez valaha döntés volt.
A döntés, szabályként megfogalmazva
Cserélje a láncot, ha irányítja a kibocsátót és fel tudja sorolni fogyasztóit. Ha nem, eszkaláljon a kibocsátóhoz. A szintet csak dátumozott, korlátozott kivételként csökkentse, a cserével már ütemezve. Bármi más ugyanazt a tanúsítványt hagyja a helyén, és kevésbé látható helyre mozgatja a kockázatot.
Ezután tesztelje újra a profilt tiszta ügyfélről, erősítse meg, hogy a kézfogás lezajlik, és ha még mindig elbukik, őrizze meg az elutasítás pontos szövegét. A pontos hibaüzenet a legolcsóbb dolog, amit a következő réteg tulajdonosának adhat.