На Nebula му требаат три датотеки: CA, сертификат на домаќин и клуч на домаќин

Ако некому му дадете папка Nebula, тој обично ќе го копира целото, вклучително и датотеката што никогаш не треба да ја напушти вашата работна станица. Збунувањето е разбирливо, бидејќи трите датотеки во PKI блокот на домаќин изгледаат слично и две од нив се сертификати. Секоја одговара на друго прашање, и само две од нив припаѓаат на јазолот. Подредете ги по улога пред да копирате нешто.

Три датотеки, три различни работи

CA сертификатот е сидро на доверба: му кажува на домаќинот на кои органи да верува кога друг домаќин ја претставува својата идентификација. Сертификатот на домаќин е сопственото уверение на јазолот, потпишано од тој орган. Клучот на домаќин е соодветната приватна половина и припаѓа на точно една машина. Јазол со CA сертификат и сопствен пар може да се приклучи на overlay и да докаже кој е. Јазол со туѓ клуч исто така може да се претстави како таа личност, и токму таа грешка оваа поставеност треба да ја спречи.

Затоа копирањето работна папка на домаќин на втора машина не е кратенка. Тоа е дуплирана идентификација со предвидлив исход.

Клучот за потпис никогаш не патува

CA клучот за потпис не е дел од ниедна конфигурација на домаќин. Тој создава нови идентитети, и кој го има може да издаде сертификат за која било overlay адреса и која било група. Соговорниците им треба само јавниот CA сертификат за да ги проверат потписите, затоа приватната половина воопшто нема улога на клиент. Чувајте го на машината каде што се издаваат сертификати, и случајна копија третирајте ја како инцидент, а не како погодност.

Ако повеќе луѓе треба да издаваат сертификати, дајте им процес наместо копија од клучот. Споделен клуч за потпис на преносен сметач е власт што никој не може да ја ревидира или отповика.

Што има внатре во сертификатот на домаќин

Сертификатот на домаќин врзува со клуч повеќе од име на датотека. Тој ја носи overlay адресата на јазолот, неговото име и членството во група, сето потпишано за да може соговорникот да одлучи дали да го прифати. Затоа преименувањето на домаќин значи издавање нов сертификат, а не уредување на конфигурациска линија.

nebula-cert print -path host.crt покажува што навистина е издадено. Прочитајте го пред да претпоставите дека сертификатот ја носи адресата што сте ја намениле.

Повторното вчитување не е секогаш доволно

Некои PKI поставки се вчитуваат повторно на сигнал, а некои не. Сертификат чија overlay адреса се промени е класичниот случај што бара повторно стартување на процесот, а не повторно вчитување.

Проверете кои патеки процесот што работи навистина ги отворил, а не само кои патеки ги наведува конфигурациската датотека. Потоа сменете едно уверение, проверете поврзаноста и дневниците, и дури потоа фатете го следното. Повторно вчитување што изгледа успешно додека стариот сертификат останува во меморијата создава несовпаѓање што изгледа како проблем со рутирање. Рестартирањето е ефтино; отстранувањето грешки во идентитет што половина overlay го гледа на стариот начин не е.

Отстранувањето на идентитет бара список за блокирање

Замената на изгубено или откриено уверение има две половини. Новиот сертификат го враќа пристапот, а стариот идентитет мора да престане да се прифаќа. Тоа се одделни операции, и правењето само на првата го остава компромитираното уверение валидно.

Списокот за блокирање е датотека што ја распределувате до домаќините, а не нешто што lighthouse го испраќа сам. Испланирајте како ќе стигне до секој јазол, вклучително и тие што денес се офлајн, и запишете кои отпечатоци сте ги блокирале. Ротирајте го клучот на машината што издава и чувајте ги деталите на новиот сертификат со записот за домаќинот. Отповикување што постои само на машината што сте ја уредиле не е отповикување.