Nebula behöver tre filer: CA, värdcertifikat och värdnyckel

Ger du någon en Nebula-katalog kopierar hen oftast allt, inklusive filen som aldrig ska lämna din arbetsstation. Förvirringen är begriplig, för de tre filerna i en värds PKI-block ser likadana ut och två av dem är certifikat. Var och en svarar på en annan fråga, och bara två av dem hör hemma på noden. Sortera dem efter roll innan du kopierar något.

Tre filer, tre olika jobb

CA-certifikatet är ett förtroendeankare: det talar om för en värd vilka myndigheter som ska betros när en annan värd presenterar sin identitet. Värdcertifikatet är nodens egen legitimation, signerad av den myndigheten. Värdnyckeln är den matchande privata halvan, och den tillhör exakt en maskin. En nod med CA-certifikatet och sitt eget par kan ansluta till overlayen och bevisa vem den är. En nod med någon annans nyckel kan också utge sig för att vara den personen, och det är felet som den här ordningen ska förhindra.

Att kopiera en fungerande värdkatalog till en andra maskin är därför ingen genväg. Det är en duplicerad identitet med ett förutsägbart utfall.

Signeringsnyckeln reser aldrig

CA-signeringsnyckeln ingår inte i någon värdkonfiguration. Den skapar nya identiteter, och den som har den kan utfärda ett certifikat för vilken overlay-adress och vilken grupp som helst. Peers behöver bara det publika CA-certifikatet för att verifiera signaturer, så den privata halvan har ingen roll på en klient alls. Förvara den på maskinen där certifikat utfärdas, och behandla en oavsiktlig kopia som en incident, inte som en bekvämlighet.

Om flera personer behöver utfärda certifikat, ge dem en process i stället för en kopia av nyckeln. En delad signeringsnyckel på en bärbar dator är en myndighet som ingen kan granska eller återkalla.

Vad som finns i ett värdcertifikat

Ett värdcertifikat binder mer än ett filnamn till en nyckel. Det bär nodens overlay-adress, dess namn och gruppmedlemskap, allt signerat så att en peer kan avgöra om den ska acceptera det. Därför innebär att byta namn på en värd att ett nytt certifikat utfärdas, inte att en konfigurationsrad redigeras.

nebula-cert print -path host.crt visar vad som faktiskt utfärdades. Läs det innan du antar att certifikatet bär den adress du avsåg.

Omladdning räcker inte alltid

Vissa PKI-inställningar laddas om vid en signal, andra inte. Ett certifikat vars overlay-adress har ändrats är det klassiska fallet som kräver omstart av processen i stället för omladdning.

Bekräfta vilka sökvägar den körande processen faktiskt öppnade, inte bara vilka sökvägar konfigurationsfilen namnger. Byt sedan en legitimation, verifiera anslutning och loggar, och rör först därefter nästa. En omladdning som verkar lyckas medan det gamla certifikatet stannar i minnet ger en avvikelse som ser ut som ett routingproblem. Omstart är billigt; att felsöka en identitet som halva overlayen fortfarande ser på det gamla sättet är det inte.

Att ta bort en identitet kräver en blockeringslista

Att ersätta en förlorad eller röjd legitimation har två halvor. Det nya certifikatet återställer åtkomsten, och den gamla identiteten måste sluta accepteras. Det är separata operationer, och att bara göra den första lämnar den komprometterade legitimationen giltig.

Blockeringslistan är en fil du distribuerar till värdar, inte något en lighthouse skickar ut själv. Planera hur den når varje nod, inklusive de som är offline i dag, och anteckna vilka fingeravtryck du blockerade. Rotera nyckeln på den utfärdande maskinen och förvara uppgifterna om det nya certifikatet med värdposten. En återkallelse som bara finns på maskinen du redigerade är ingen återkallelse.