Nebula kræver tre filer: CA, værtscertifikat og værtsnøgle

Giver du nogen en Nebula-mappe, kopierer de som regel det hele, inklusive den fil, der aldrig bør forlade din arbejdsstation. Forvirringen er forståelig, for de tre filer i en værts PKI-blok ligner hinanden, og to af dem er certifikater. Hver af dem svarer på et forskelligt spørgsmål, og kun to af dem hører på noden. Sortér dem efter rolle, før du kopierer noget.

Tre filer, tre forskellige opgaver

CA-certifikatet er et tillidsanker: det fortæller en vært, hvilke myndigheder den skal tro på, når en anden vært fremviser sin identitet. Værtscertifikatet er nodens egen legitimation, underskrevet af den myndighed. Værtsnøglen er den matchende private halvdel, og den tilhører præcis én maskine. En node med CA-certifikatet og sit eget par kan slutte sig til overlayet og bevise, hvem den er. En node med en andens nøgle kan også udgive sig for at være den person, og det er den fejl, som dette arrangement skal forhindre.

At kopiere en fungerende værtsmappe til en anden maskine er derfor ikke en genvej. Det er en duplikeret identitet med et forudsigeligt resultat.

Signeringsnøglen rejser aldrig

CA-signeringsnøglen er ikke en del af nogen værtskonfiguration. Den skaber nye identiteter, og den, der har den, kan udstede et certifikat til enhver overlay-adresse og enhver gruppe. Peers har kun brug for det offentlige CA-certifikat til at verificere signaturer, så den private halvdel har slet ingen rolle på en klient. Opbevar den på den maskine, hvor certifikater udstedes, og behandl en tilfældig kopi som en hændelse, ikke som en bekvemmelighed.

Hvis flere personer skal udstede certifikater, så giv dem en proces i stedet for en kopi af nøglen. En delt signeringsnøgle på en laptop er en myndighed, som ingen kan revidere eller tilbagekalde.

Hvad der er inde i et værtscertifikat

Et værtscertifikat binder mere end et filnavn til en nøgle. Det bærer nodens overlay-adresse, dens navn og dens gruppemedlemskab, alt sammen underskrevet, så en peer kan afgøre, om den skal acceptere det. Derfor betyder omdøbning af en vært, at der skal udstedes et nyt certifikat, ikke at en konfigurationslinje redigeres.

nebula-cert print -path host.crt viser, hvad der faktisk blev udstedt. Læs den, før du antager, at et certifikat bærer den adresse, du havde tænkt dig.

Genindlæsning er ikke altid nok

Nogle PKI-indstillinger genindlæses ved et signal, og nogle gør ikke. Et certifikat, hvis overlay-adresse er ændret er det klassiske tilfælde, der kræver en genstart af processen i stedet for en genindlæsning.

Bekræft, hvilke stier den kørende proces faktisk åbnede, ikke bare hvilke stier konfigurationsfilen nævner. Skift derefter én legitimation, verificér forbindelse og logfiler, og rør først derefter den næste. En genindlæsning, der ser ud til at lykkes, mens det gamle certifikat bliver i hukommelsen, giver en uoverensstemmelse, der ligner et routingproblem. En genstart er billig; at fejlfinde en identitet, som halvdelen af overlayet stadig ser den gamle vej, er ikke.

Fjernelse af en identitet kræver en blokeringsliste

Udskiftning af en mistet eller afsløret legitimation har to halvdele. Det nye certifikat giver adgang igen, og den gamle identitet skal holde op med at blive accepteret. Det er to separate handlinger, og hvis man kun gør den første, forbliver den kompromitterede legitimation gyldig.

Blokeringslisten er en fil, du distribuerer til værter, ikke noget en lighthouse sender ud af sig selv. Planlæg, hvordan den når hver node, inklusive dem, der er offline i dag, og noter, hvilke fingeraftryk du har blokeret. Rotér nøglen på den udstedende maskine, og opbevar det nye certifikats oplysninger sammen med værtsregistreringen. En tilbagekaldelse, der kun findes på den maskine, du redigerede, er ikke en tilbagekaldelse.