Varför kopiering av ca.key till varje VPN-klient förstör CA:n

Någonstans i installationsanvisningarna kopieras en hel katalog rakt av till varje bärbar dator eftersom det var enklare än att avgöra vilka filer som hör dit. Den katalogen innehåller ca.key, och i samma stund den når en andra enhet upphör certifikatmyndigheten att vara en myndighet. Varje innehavare kan nu utfärda identiteter som resten av nätet kommer att lita på.

Den här förvirringen är värd att reda ut en gång, eftersom de två filerna ser lika ut och gör motsatta saker.

Verifieringsmaterial och signeringsmaterial

En klient behöver CA:ns offentliga certifikat för att kontrollera att certifikatet som en motpart presenterar har signerats av den myndigheten. Det är en verifieringsuppgift och den kräver ingen hemlighet alls. Att signera en motparts certifikat är en annan uppgift, som utförs en gång av den som driver CA:n, med den privata nyckeln som aldrig lämnar sitt skyddade förvar. Att hålla dessa två uppgifter åtskilda är hela poängen med att leverera två filer.

Så ca.crt hör hemma i profilen och ca.key hör inte hemma någonstans i närheten av den. Filnamnen är en konvention, inte en garanti, och därför måste typen undersökas i stället för att slutas från namnet.

En arkitektur med en mellanliggande CA eller en nätbaserad utfärdandetjänst är inget undantag. Det är det vanliga sättet att hålla signeringsförmågan borta från ändpunkterna medan enhetscertifikat fortfarande utfärdas i stor skala.

Vad en klient ska bevisa med sin egen nyckel

Varje enhet får sitt eget nyckelpar och sitt eget certifikat, signerat en gång av CA:n. Klienten lägger fram det certifikatet och bevisar att den har den matchande privata nyckeln, och servern avgör om den ska acceptera det. Det är identiteten som återkallas när en bärbar dator tappas bort.

Kontrasten spelar störst roll efter en stöld. Med identiteter per enhet tas en exponerad klient bort genom återkallelse eller genom att motparten tas bort, och resten av flottan fortsätter att fungera.

En läckt myndighetsnyckel kan inte hanteras så. Varje certifikat den någonsin signerat eller kunnat signera blir misstänkt, så svaret är ett utbyte av förtroendet och inte en enda återkallelse. Det är ett projekt, inte ett ärende.

Läs en fil innan du kopierar den någonstans

Två kommandon berättar vilken sorts objekt du håller i handen utan att skriva ut någon hemlighet. Det första anger subjektet och CA-flaggan på ett certifikat; det andra validerar en nyckel och rapporterar dess typ. Kör båda på filerna i paketet du är på väg att distribuera. Allt som valideras som en privat nyckel hör inte hemma i en klientkatalog.

openssl x509 -in ca.crt -noout -subject -ext basicConstraints
openssl pkey -in ca.key -noout -check

Om det andra kommandot lyckas på en fil som ligger i ett klientpaket, stanna och behandla paketet som komprometterat. Utdata som säger att en nyckel är giltig säger också att den finns, och förekomsten är hela problemet.

Lägg också märke till den andra riktningen: en klientprofil innehåller med rätta den klientens egen privata nyckel. Att radera varje nyckel du hittar bryter anslutningen utan att förbättra något, så objektet måste identifieras innan det tas bort.

Att begränsa en nyckel du redan distribuerat

Utgå inte från att raderingen av den lokala kopian återställer exponeringen. Alla som haft filen kan ha kopierat den, och det säkra antagandet är att de gjorde det. Följ operatörens incidentprocess och byt ut förtroendeankaret, genom att utfärda enhetscertifikat på nytt under en ny CA.

Ändra sedan den paketering som skapade problemet. Skicka en kataloglista med en uttrycklig lista över tillåtna filer, håll CA-nyckeln på en maskin som aldrig ansluter till klientflottan, och notera vilket system som förvarar den.

Om myndigheten måste utfärda ofta, flytta signeringen bakom en tjänst eller en mellanliggande med snävt omfång och kort giltighet. Då blottar ett framtida misstag en delmängd av utfärdandet och inte förtroenderoten för hela utrullningen.