Hvorfor kopiering af ca.key til hver VPN-klient ødelægger CA’en

Et sted i opsætningsvejledningen kopieres en mappe råt til hver bærbar, fordi det var lettere end at beslutte, hvilke filer der hører der. Den mappe indeholder ca.key, og i det øjeblik den når en anden enhed, holder certifikatmyndigheden op med at være en myndighed. Enhver indehaver kan nu udstede identiteter, som resten af netværket vil stole på.

Forvirringen er værd at rede ud én gang, fordi de to filer ligner hinanden og gør det modsatte.

Verifikationsmateriale og signeringsmateriale

En klient har brug for CA’ens offentlige certifikat for at kontrollere, at det certifikat, en modpart fremlægger, er signeret af den myndighed. Det er en verifikationsopgave og kræver ingen hemmelighed. At signere en modparts certifikat er en anden opgave, som udføres én gang af den, der driver CA’en, med den private nøgle, der aldrig forlader sin beskyttede opbevaring. At holde de to opgaver adskilt er hele pointen med at levere to filer.

Så ca.crt hører i profilen, og ca.key hører ingen steder i nærheden af den. Filnavnene er en konvention, ikke en garanti, og derfor skal typen undersøges i stedet for at blive udledt af navnet.

En arkitektur med en mellemliggende CA eller en online udstedelsestjeneste er ingen undtagelse. Det er den standardmåde at holde signeringskapacitet væk fra slutenheder, mens enhedscertifikater stadig udstedes i stor skala.

Hvad en klient skal bevise med sin egen nøgle

Hver enhed får sit eget nøglepar og sit eget certifikat, signeret én gang af CA’en. Klienten fremlægger det certifikat og beviser, at den besidder den matchende private nøgle, og serveren afgør, om den vil acceptere det. Det er den identitet, der tilbagekaldes, når en bærbar mistes.

Kontrasten betyder mest efter et tyveri. Med identiteter per enhed fjernes én blotlagt klient ved tilbagekaldelse eller ved at fjerne modparten, og resten af flåden fortsætter med at virke.

En lækket myndighedsnøgle kan ikke håndteres sådan. Hvert certifikat, den nogensinde har signeret eller kunne signere, bliver mistænkeligt, så svaret er en udskiftning af tilliden frem for en enkelt tilbagekaldelse. Det er et projekt, ikke en sag.

Læs en fil, før du kopierer den nogen steder hen

To kommandoer fortæller dig, hvilken slags objekt du har i hånden, uden at udskrive nogen hemmelighed. Den første angiver subjektet og CA-flaget på et certifikat; den anden validerer en nøgle og rapporterer dens type. Kør begge på filerne i den pakke, du er ved at distribuere. Alt, der valideres som en privat nøgle, hører ikke i en klientmappe.

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

Hvis den anden kommando lykkes på en fil, der ligger i en klientpakke, skal du stoppe og behandle pakken som kompromitteret. Output, der siger, at en nøgle er gyldig, siger også, at den er til stede, og tilstedeværelsen er hele problemet.

Bemærk også den anden retning: en klientprofil indeholder med rette den pågældende klients egen private nøgle. Sletning af hver nøgle, du finder, bryder forbindelsen uden at forbedre noget, så objektet skal identificeres, før det fjernes.

At inddæmme en nøgle, du allerede har distribueret

Antag ikke, at sletning af den lokale kopi gør eksponeringen om. Enhver, der har haft filen, kan have kopieret den, og den sikre antagelse er, at de gjorde. Følg operatørens hændelsesproces, og udskift tillidsankeret, og genudsted enhedscertifikater under en ny CA.

Skift derefter den pakning, der skabte problemet. Send en mappeliste med en eksplicit tilladelsesliste over filer, hold CA-nøglen på en maskine, der aldrig slutter sig til klientflåden, og noter, hvilket system der opbevarer den.

Hvis myndigheden skal udstede hyppigt, flyt signeringen bag en tjeneste eller en mellemliggende med snævert omfang og kort gyldighed. På den måde blotlægger en fremtidig fejl en delmængde af udstedelsen i stedet for roden af tilliden til hele udrulningen.