Nebula патрабуе тры файлы: сертыфікат CA, сертыфікат хоста, ключ хоста

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

Тры файлы, тры розныя задачы

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

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

Ключ подпісу ніколі не падарожнічае

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

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

Што ўнутры сертыфіката хоста

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

nebula-cert print -path host.crt паказвае, што было выдадзена насамрэч. Прачытайце яго, перш чым меркаваць, што сертыфікат змяшчае патрэбны вам адрас.

Перазагрузкі не заўсёды дастаткова

Некаторыя налады PKI перазагружаюцца па сігнале, а некаторыя не. Сертыфікат, адрас якога ў overlay змяніўся — класічны выпадак, які патрабуе перазапуску працэсу, а не перазагрузкі.

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

Выдаленне асобы патрабуе спісу блакавання

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

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