Чаму капіраванне ca.key на кожны кліент VPN ламае CA

Дзесьці ў інструкцыі па наладзе цэлы каталог капіруюць на кожны ноўтбук, бо гэта было прасцей, чым вырашыць, якія файлы там павінны быць. У гэтым каталогу ляжыць ca.key, і ў той момант, калі ён трапляе на другую прыладу, цэнтр сертыфікацыі перастае быць цэнтрам. Цяпер любы ўладальнік можа выпускаць ідэнтычнасці, якім будзе давяраць уся астатняя сетка.

Гэтую блытаніну варта разабраць адзін раз, бо два файлы выглядаюць падобна, а робяць процілеглыя рэчы.

Матэрыял праверкі і матэрыял подпісу

Кліенту патрэбны публічны сертыфікат CA, каб праверыць, што сертыфікат, прадстаўлены суразмоўцам, быў падпісаны гэтым цэнтрам. Гэта задача праверкі, і яна зусім не патрабуе сакрэту. Подпіс сертыфіката суразмоўцы — іншая задача, яна выконваецца адзін раз тым, хто кіруе CA, прыватным ключом, які ніколі не пакідае абароненае сховішча. Трымаць гэтыя дзве задачы асобна — увесь сэнс адпраўкі двух файлаў.

Такім чынам, ca.crt належыць профілю, а ca.key не належыць нікуды паблізу. Імёны файлаў — гэта ўмоўнасць, а не гарантыя, таму тып трэба правяраць, а не выводзіць з назвы.

Архітэктура з прамежкавым CA або анлайн-сэрвісам выпуску не з’яўляецца выключэннем. Гэта стандартны спосаб трымаць магчымасць падпісу далей ад канцавых прылад, выпускаючы сертыфікаты прылад у маштабе.

Што кліент павінен даказаць сваім ключом

Кожная прылада атрымлівае ўласную пару ключоў і ўласны сертыфікат, падпісаны адзін раз CA. Кліент прад’яўляе гэты сертыфікат і даказвае валоданне адпаведным прыватным ключом, а сервер вырашае, ці прымаць яго. Менавіта гэтая ідэнтычнасць адклікаецца, калі ноўтбук губляецца.

Кантраст найбольш важны пасля крадзяжу. З ідэнтычнасцямі для кожнай прылады адзін раскрыты кліент выдаляецца адкліканнем або выдаленнем суразмоўцы, і астатні флот працягвае працаваць.

З уцечкай ключа цэнтра так зрабіць нельга. Кожны сертыфікат, які ён калі-небудзь падпісаў або мог падпісаць, становіцца падазроным, таму адказ — замена даверу, а не асобнае адкліканне. Гэта праект, а не заяўка.

Прачытайце файл, перш чым капіраваць яго куды-небудзь

Дзве каманды паведамяць, які тып аб’екта ў вас у руках, не друкуючы ніякага сакрэту. Першая называе суб’ект і сцяг CA ў сертыфікаце; другая правярае ключ і паведамляе яго тып. Запусціце абедзве для файлаў у наборы, які вы збіраецеся распаўсюджваць. Усё, што правяраецца як прыватны ключ, не належыць у каталог кліента.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Калі другая каманда паспяхова выканалася для файла, які ляжыць у наборы кліента, спыніцеся і лічыце набор скампраметаваным. Вывад, які сведчыць, што ключ сапраўдны, сведчыць таксама, што ён прысутнічае, а прысутнасць — гэта ўся праблема.

Звярніце ўвагу і на іншы кірунак: профіль кліента законна змяшчае ўласны прыватны ключ гэтага кліента. Выдаленне кожнага знойдзенага ключа ламае злучэнне, нічога не паляпшаючы, таму аб’ект трэба ідэнтыфікаваць перад выдаленнем.

Стрымаць ключ, які вы ўжо распаўсюдзілі

Не мяркуйце, што выдаленне лакальнай копіі адмяняе ўцечку. Любы, хто меў файл, мог яго скапіраваць, і бяспечнае меркаванне — што так і было. Ідзіце па працэсе інцыдэнтаў аператара і заменіце якар даверу, перавыпусціўшы сертыфікаты прылад пад новым CA.

Затым змяніце ўпакоўку, якая стварыла праблему. Адпраўляйце спіс каталога з яўным белым спісам файлаў, трымайце ключ CA на машыне, якая ніколі не далучаецца да флоту кліентаў, і запішыце, якая сістэма яго захоўвае.

Калі цэнтр павінен выпускаць часта, перанясіце подпіс за сэрвіс або прамежкавы цэнтр з вузкім ахопам і кароткім тэрмінам дзеяння. Так будучая памылка адкрые частку выпуску, а не корань даверу ўсяго разгортвання.