Kvifor kopiering av ca.key til kvar VPN-klient øydelegg CA-en

Ein stad i oppsettrettleiinga vert ei mappe råkopiert til kvar berbare PC fordi det var enklare enn å avgjere kva filer som høyrer heime der. Den mappa inneheld ca.key, og i det augneblinken ho når ei anna eining, sluttar sertifikatstyresmakta å vere ei styresmakt. Kvar innehavar kan no gje ut identitetar som resten av nettet vil stole på.

Denne forvirringa er verd å nøste opp éin gong, fordi dei to filene ser like ut og gjer motsette ting.

Stadfestingsmateriell og signeringsmateriell

Ein klient treng det offentlege sertifikatet til CA-en for å kontrollere at sertifikatet som ein motpart legg fram, er signert av den styresmakta. Det er ei stadfestingsoppgåve og krev inga hemmelegheit i det heile. Å signere sertifikatet til ein motpart er ei anna oppgåve, utført éin gong av den som driv CA-en, med den private nøkkelen som aldri forlèt det verna lageret sitt. Å halde desse to oppgåvene fråskilde er heile poenget med å levere to filer.

Så høyrer ca.crt heime i profilen, og ca.key høyrer ikkje heime nokon stad i nærleiken av han. Filnamna er ein konvensjon, ikkje ein garanti, og difor må typen undersøkjast i staden for å utleiast frå namnet.

Ein arkitektur med ein mellomliggjande CA eller ein nettbasert utferdsteneste er ikkje noko unntak. Det er den vanlege måten å halde signeringskapasitet borte frå endepunkta medan einingssertifikat framleis vert gjevne ut i stor skala.

Kva ein klient skal bevise med sin eigen nøkkel

Kvar eining får sitt eige nøkkelpar og sitt eige sertifikat, signert éin gong av CA-en. Klienten legg fram sertifikatet og beviser at han har den tilhøyrande private nøkkelen, og tenaren avgjer om han vil godta det. Dette er identiteten som vert trekt tilbake når ein berbar PC vert mist.

Kontrasten tel mest etter eit tjuveri. Med identitetar per eining vert éin avdekt klient fjerna ved tilbaketrekking eller ved å fjerne motparten, og resten av flåten held fram med å verke.

Ein leka styresmaktsnøkkel kan ikkje handsamast slik. Kvart sertifikat han nokon gong har signert eller kunne signere, vert mistenkjeleg, så svaret er ei utskifting av tilliten og ikkje éi enkel tilbaketrekking. Det er eit prosjekt, ikkje ei sak.

Les ei fil før du kopierer ho nokon stad

To kommandoar fortel deg kva slags objekt du held i handa utan å skrive ut noka hemmelegheit. Den første nemner subjektet og CA-flagget på eit sertifikat; den andre validerer ein nøkkel og rapporterer typen. Køyr begge på filene i pakken du er i ferd med å distribuere. Alt som validerer som ein privat nøkkel, høyrer ikkje heime i ei klientmappe.

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

Viss den andre kommandoen lykkast på ei fil som ligg i ein klientpakke, stopp og handsam pakken som kompromittert. Utdata som seier at ein nøkkel er gyldig, seier òg at han er til stades, og tilstadeveringa er heile problemet.

Legg òg merke til den andre retninga: ein klientprofil inneheld med rette den private nøkkelen til den klienten. Å slette kvar nøkkel du finn, bryt sambandet utan å betra noko, så objektet må identifiserast før det vert fjerna.

Å demme inn ein nøkkel du allereie har distribuert

Ikkje gå ut frå at sletting av den lokale kopien reverserer eksponeringa. Alle som har hatt fila, kan ha kopiert ho, og den trygge føresetnaden er at dei gjorde det. Følg hendingsprosessen til operatøren og skift ut tillitsankeret, og gjev ut einingens sertifikat på nytt under ein ny CA.

Deretter endrar du pakkinga som skapte problemet. Send ei mappeliste med ei uttrykkeleg liste over tillatne filer, hald CA-nøkkelen på ein maskin som aldri vert med i klientflåten, og noter kva system som har han.

Viss styresmakta må gje ut ofte, flytt signeringa bak ein teneste eller ein mellomliggjande med snevert omfang og kort gyldigheit. Då avdekkjer ein framtidig feil ein delmengd av utferda og ikkje tillitsrota for heile utrullinga.