Hvorfor kopiering av ca.key til hver VPN-klient ødelegger CA-en

Et sted i oppsettveiledningen kopieres en mappe råkopiert til hver bærbar PC fordi det var enklere enn å avgjøre hvilke filer som hører hjemme der. Den mappen inneholder ca.key, og i det øyeblikket den når en annen enhet, slutter sertifikatmyndigheten å være en myndighet. Enhver innehaver kan nå utstede identiteter som resten av nettverket vil stole på.

Forvirringen er verdt å nøste opp én gang, fordi de to filene ser like ut og gjør motsatte ting.

Verifikasjonsmateriale og signeringsmateriale

En klient trenger CA-ens offentlige sertifikat for å kontrollere at sertifikatet som en motpart legger fram, er signert av den myndigheten. Det er en verifikasjonsoppgave og krever ingen hemmelighet i det hele tatt. Å signere en motparts sertifikat er en annen oppgave, utført én gang av den som driver CA-en, med den private nøkkelen som aldri forlater sitt beskyttede lager. Å holde disse to oppgavene atskilt er hele poenget med å levere to filer.

Så ca.crt hører hjemme i profilen, og ca.key hører ikke hjemme noe sted i nærheten av den. Filnavnene er en konvensjon, ikke en garanti, og derfor må typen undersøkes i stedet for å utledes fra navnet.

En arkitektur med en mellomliggende CA eller en nettbasert utstedelsestjeneste er ikke et unntak. Det er den vanlige måten å holde signeringskapasitet borte fra endepunktene mens enhetssertifikater fortsatt utstedes i stor skala.

Hva en klient skal bevise med sin egen nøkkel

Hver enhet får sitt eget nøkkelpar og sitt eget sertifikat, signert én gang av CA-en. Klienten legger fram sertifikatet og beviser at den har den tilhørende private nøkkelen, og serveren avgjør om den vil godta det. Dette er identiteten som tilbakekalles når en bærbar PC mistes.

Kontrasten betyr mest etter en tyveri. Med identiteter per enhet fjernes én avslørt klient ved tilbakekalling eller ved å fjerne motparten, og resten av flåten fortsetter å virke.

En lekket myndighetsnøkkel kan ikke håndteres slik. Hvert sertifikat den noen gang har signert eller kunne signere, blir mistenkelig, så svaret er en utskifting av tilliten og ikke én enkelt tilbakekalling. Det er et prosjekt, ikke en sak.

Les en fil før du kopierer den noe sted

To kommandoer forteller deg hva slags objekt du holder i hånden uten å skrive ut noen hemmelighet. Den første angir subjektet og CA-flagget på et sertifikat; den andre validerer en nøkkel og rapporterer typen. Kjør begge på filene i pakken du er i ferd med å distribuere. Alt som valideres som en privat nøkkel, hører ikke hjemme i en klientmappe.

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

Hvis den andre kommandoen lykkes på en fil som ligger i en klientpakke, stopp og behandle pakken som kompromittert. Utdata som sier at en nøkkel er gyldig, sier også at den er til stede, og tilstedeværelsen er hele problemet.

Legg også merke til den andre retningen: en klientprofil inneholder med rette den aktuelle klientens egen private nøkkel. Å slette hver nøkkel du finner, bryter forbindelsen uten å forbedre noe, så objektet må identifiseres før det fjernes.

Å inndemme en nøkkel du allerede har distribuert

Ikke anta at sletting av den lokale kopien reverserer eksponeringen. Alle som har hatt filen, kan ha kopiert den, og den trygge antakelsen er at de gjorde det. Følg operatørens hendelsesprosess og skift ut tillitsankeret, og utsted enhetssertifikater på nytt under en ny CA.

Deretter endrer du pakkingen som skapte problemet. Send en mappeliste med en uttrykkelig tillatt-liste over filer, hold CA-nøkkelen på en maskin som aldri blir med i klientflåten, og noter hvilket system som har den.

Hvis myndigheten må utstede ofte, flytt signeringen bak en tjeneste eller en mellomliggende med snevert omfang og kort gyldighet. Da avdekker en framtidig feil en delmengde av utstedelsen og ikke tillitsroten for hele utrullingen.