ca md too weak: да преиздадем сертификата или да свалим нивото?

OpenVPN клиент, който работеше миналия месец, сега се проваля при стартиране с ca md too weak, а профилът на диска е байт по байт същият, който работеше. Съобщението засяга подписа върху сертификата на сертификатния орган, а не шифъра на данните, auth диджеста или паролата на акаунта. Три условия решават дали поправката е нов идентификационен материал, нова верига или съзнателна промяна в политиката. Минарете ги по ред и избягвате обичайния изход, при който тунелът се връща чрез отслабване на всяка TLS връзка на хоста.

Какво всъщност назовава грешката

OpenSSL повдига тази грешка при проверка, докато изгражда верига, когато сертификатът, действащ като CA, носи диджест на подписа, който нивото на сигурност на библиотеката вече не приема. MD5 се отхвърля на нивото по подразбиране, а SHA-1 се отхвърля, щом нивото бъде повишено. Диджестът на крайния сертификат тук е по-маловажен от диджеста на издателя, който го подписва. Същата политика може да отхвърли корен, който в деня на издаването си е бил напълно обикновен.

Затова редактирането на auth или data-ciphers не прави нищо за този провал. Тези настройки управляват как пакетите се защитават след ръкостискането, докато отхвърленият обект е документ за самоличност, който се преглежда преди да съществува тунел. Един сертификат може спокойно да стои в срока си на валидност и въпреки това да носи подпис, който библиотеката няма да приеме.

Дръжте проверките отделно в главата си и грешката спира да изглежда загадъчна. Датите на валидност, използването на ключа и диджестът на подписа са независими тестове и точно един от тях току-що се провали.

Условие първо: отхвърленият обект коренът ли е?

Отпечатайте всеки сертификат в профила и прочетете полетата subject и issuer. Самоподписаният корен показва една и съща стойност в двете, а неговият алгоритъм за подпис е този, върху който стъпва цялата верига. Когато слабият диджест е там, всеки лист под него наследява проблема. Запишете алгоритъма до subject, за да е механично, а не по памет, следващото сравнение.

Обединените CA файлове често съдържат няколко блока, затова идентифицирайте блока, който реално се зарежда, вместо да предполагате, че първият е виновен. Командата openssl x509 -in ca.pem -noout -subject -issuer -text описва един сертификат наведнъж, което означава първо да разделите пакета, ако съдържа повече. Сравнете отпечатания алгоритъм за подпис с диджеста, който бихте очаквали от епохата, в която е създаден коренът.

Лист, подписан с SHA-256 под слаб корен, пак се проваля, защото проверката на веригата върви чак до горе. Именно този ред прави следващото условие важно.

Условие второ: контролирате ли издателя?

Ако коренът принадлежи на вашата организация, трайната поправка е нов корен със съвременен диджест плюс преиздадени листове, доставени като едно обновяване на профила. Това струва прозорец за поддръжка и план за устройства, които не могат да получат обновяването в същия ден.

Ако веригата е издадена от трета страна, поправката е заявка до този оператор, а единственото полезно локално действие е да спрете да разчитате на стария материал. Редактирането на PEM текста или презаписването на файла не променя нищо, което подписът покрива.

Един междинен случай заслужава име: вътрешен корен, който предхожда текущите настройки по подразбиране, но все още подписва материал, на който други системи се доверяват. Замяната му означава одит на всеки потребител, включително устройства, които заковават стария сертификат по отпечатък. Пребройте тези потребители, преди да насрочите промяната, защото смяна на корен, която пропусне един, разменя грешка при стартиране срещу прекъсване.

Условие трето: какво още приема понижаването на нивото

Понижаването на нивото на сигурност или изборът на стария профил за сертификати на OpenVPN кара клиента отново да приема стария диджест. То също отпуска други проверки в същата библиотека, за всяка връзка, която този процес прави.

Това може да е защитимо в лаборатория или като кратък мост, докато се подготвя материал за замяна, стига изключението да е ограничено до един профил и да носи крайна дата. Като постоянна настройка на споделен хост то тихо разширява това, на което всеки TLS клиент там ще се доверява.

Запишете изключението със собственик и стъпка за премахване. Недокументирана промяна на нивото е неразличима от грешка след шест месеца и следващият инженер няма да знае, че някога е било решение.

Решението, записано като правило

Заменете веригата, когато контролирате издателя и можете да изброите потребителите му. Ескалирайте до издателя, когато не можете. Понижавайте нивото само като датирано, ограничено изключение с вече насрочена замяна. Всичко друго оставя същия сертификат на място и мести риска някъде по-малко видимо.

След това тествайте отново профила от чист клиент, потвърдете, че ръкостискането завършва, и запазете точния текст на отказа, ако той продължава. Прецизното съобщение за грешка е най-евтиното, което можете да дадете на този, който притежава следващия слой.