Nebula trenger tre filer: CA, vertssertifikat og vertsnøkkel

Gir du noen en Nebula-katalog, kopierer de vanligvis alt, inkludert filen som aldri skal forlate arbeidsstasjonen din. Forvirringen er forståelig, for de tre filene i en verts PKI-blokk ser like ut, og to av dem er sertifikater. Hver av dem svarer på et ulikt spørsmål, og bare to av dem hører hjemme på noden. Sorter dem etter rolle før du kopierer noe.

Tre filer, tre ulike jobber

CA-sertifikatet er et tillitsanker: det forteller en vert hvilke myndigheter den skal tro på når en annen vert legger fram identiteten sin. Vertssertifikatet er nodens egen legitimasjon, signert av den myndigheten. Vertsnøkkelen er den matchende private halvdelen, og den tilhører nøyaktig én maskin. En node med CA-sertifikatet og sitt eget par kan bli med i overlayet og bevise hvem den er. En node med en annens nøkkel kan også utgi seg for å være den personen, og det er svikten denne ordningen skal hindre.

Å kopiere en fungerende vertskatalog til en annen maskin er derfor ingen snarvei. Det er en duplisert identitet med et forutsigbart utfall.

Signeringsnøkkelen reiser aldri

CA-signeringsnøkkelen er ikke en del av noen vertskonfigurasjon. Den preger nye identiteter, og den som har den, kan utstede et sertifikat for hvilken som helst overlay-adresse og hvilken som helst gruppe. Peers trenger bare det offentlige CA-sertifikatet for å verifisere signaturer, så den private halvdelen har ingen rolle på en klient i det hele tatt. Oppbevar den på maskinen der sertifikater utstedes, og behandle en tilfeldig kopi som en hendelse, ikke som en bekvemmelighet.

Hvis flere personer må utstede sertifikater, gi dem en prosess i stedet for en kopi av nøkkelen. En delt signeringsnøkkel på en bærbar PC er en myndighet ingen kan revidere eller tilbakekalle.

Hva som er inne i et vertssertifikat

Et vertssertifikat binder mer enn et filnavn til en nøkkel. Det bærer nodens overlay-adresse, navnet og gruppemedlemskapet, alt signert slik at en peer kan avgjøre om den skal godta det. Derfor betyr omdøping av en vert at det utstedes et nytt sertifikat, ikke at en konfigurasjonslinje redigeres.

nebula-cert print -path host.crt viser hva som faktisk ble utstedt. Les det før du antar at sertifikatet bærer adressen du hadde tenkt.

Ny innlasting er ikke alltid nok

Noen PKI-innstillinger lastes inn på nytt ved et signal, andre ikke. Et sertifikat hvis overlay-adresse er endret er det klassiske tilfellet som krever omstart av prosessen i stedet for ny innlasting.

Bekreft hvilke stier den kjørende prosessen faktisk åpnet, ikke bare hvilke stier konfigurasjonsfilen nevner. Bytt så én legitimasjon, verifiser tilkobling og logger, og rør først deretter den neste. En ny innlasting som ser ut til å lykkes mens det gamle sertifikatet blir liggende i minnet, gir et avvik som ser ut som et ruteproblem. Omstart er billig; å feilsøke en identitet halve overlayet fortsatt ser den gamle veien, er det ikke.

Fjerning av en identitet krever en blokkeringsliste

Utskifting av en tapt eller avslørt legitimasjon har to halvdeler. Det nye sertifikatet gjenoppretter tilgangen, og den gamle identiteten må slutte å bli godtatt. Dette er separate operasjoner, og å gjøre bare den første lar den kompromitterte legitimasjonen være gyldig.

Blokkeringslisten er en fil du distribuerer til verter, ikke noe en lighthouse sender ut av seg selv. Planlegg hvordan den når hver node, også de som er offline i dag, og noter hvilke fingeravtrykk du blokkerte. Rotér nøkkelen på den utstedende maskinen og oppbevar opplysningene om det nye sertifikatet sammen med vertsoppføringen. En tilbakekalling som bare finnes på maskinen du redigerte, er ikke en tilbakekalling.