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

Gjev du nokon ein Nebula-mappe, kopierer dei vanlegvis alt, inkludert fila som aldri skal forlata arbeidsstasjonen din. Forvirringa er forståeleg, for dei tre filene i PKI-blokka til ein vert ser like ut, og to av dei er sertifikat. Kvar av dei svarar på eit ulikt spørsmål, og berre to av dei høyrer heime på noden. Sorter dei etter rolle før du kopierer noko.

Tre filer, tre ulike jobbar

CA-sertifikatet er eit tillitsanker: det fortel ein vert kva styresmakter han skal tru på når ein annan vert legg fram identiteten sin. Vertssertifikatet er noden sin eigen legitimasjon, signert av den styresmakta. Vertsnøkkelen er den samsvarende private halvdelen, og han høyrer til nøyaktig éin maskin. Ein node med CA-sertifikatet og sitt eige par kan bli med i overlayet og prova kven han er. Ein node med nøkkelen til nokon andre kan òg gje seg ut for å vera den personen, og det er svikten denne ordninga skal hindre.

Å kopiere ei fungerande vertsmappe til ein annan maskin er derfor inga snaregata. Det er ein duplisert identitet med eit føreseieleg utfall.

Signeringsnøkkelen reiser aldri

CA-signeringsnøkkelen er ikkje del av nokon vertskonfigurasjon. Han pregar nye identitetar, og den som har han, kan gje ut eit sertifikat for kva som helst overlay-adresse og kva som helst gruppe. Jamlike treng berre det offentlege CA-sertifikatet for å stadfeste signaturar, så den private halvdelen har inga rolle på ein klient i det heile. Oppbevar han på maskinen der sertifikat blir gjevne ut, og handsam ein tilfeldig kopi som ei hending, ikkje som ei lettvintheit.

Viss fleire personar må gje ut sertifikat, gje dei ein prosess i staden for ein kopi av nøkkelen. Ein delt signeringsnøkkel på ein berbar PC er ei styresmakt ingen kan revidere eller kalle tilbake.

Kva som er inne i eit vertssertifikat

Eit vertssertifikat bind meir enn eit filnamn til ein nøkkel. Det ber overlay-adressa til noden, namnet og gruppemedlemskapen, alt signert slik at ein jamlike kan avgjere om han vil godta det. Derfor tyder omdøyging av ein vert at det blir gjeve ut eit nytt sertifikat, ikkje at ei konfigurasjonslinje blir redigert.

nebula-cert print -path host.crt viser kva som faktisk vart gjeve ut. Les det før du går ut frå at sertifikatet ber adressa du hadde tenkt.

Ny innlasting er ikkje alltid nok

Nokre PKI-innstillingar blir lasta inn på nytt ved eit signal, andre ikkje. Eit sertifikat der overlay-adressa er endra er det klassiske tilfellet som krev omstart av prosessen i staden for ny innlasting.

Stadfest kva stiar den køyrande prosessen faktisk opna, ikkje berre kva stiar konfigurasjonsfila nemner. Byta så éin legitimasjon, stadfest tilkopling og loggar, og rør først deretter den neste. Ei ny innlasting som ser ut til å lukkast medan det gamle sertifikatet blir liggjande i minnet, gjev eit avvik som ser ut som eit ruteproblem. Omstart er billeg; å feilsøkje ein identitet halve overlayet framleis ser den gamle vegen, er det ikkje.

Fjerning av ein identitet krev ei blokkeringsliste

Utskifting av ein tapt eller avdekt legitimasjon har to halvdeler. Det nye sertifikatet gjev attende tilgangen, og den gamle identiteten må slutte å bli godteken. Dette er separate handlingar, og å gjere berre den første lèt den kompromitterte legitimasjonen vera gyldig.

Blokkeringslista er ei fil du distribuerer til vertar, ikkje noko ein lighthouse sender ut av seg sjølv. Planlegg korleis ho når kvar node, òg dei som er offline i dag, og noter kva fingeravtrykk du blokkerte. Rotér nøkkelen på den utgivande maskinen og oppbevar opplysningane om det nye sertifikatet saman med vertsoppføringa. Ei tilbakekalling som berre finst på maskinen du redigerte, er ikkje ei tilbakekalling.