En OpenVPN-profil har tre sertifikatblokker: hvilken er hemmelig?

Du åpner en .ovpn-fil for å endre én linje og finner tre blokker med base64 som alle ser ut som påloggingsinformasjon. Én er trygg å publisere, én er like følsom som et passord, og én er en offentlig nøkkel som ikke betyr noe med mindre noe annet er signert med paret. Folk limer inn hele filen i en støttetråd fordi blokkene ser ut til å kunne byttes om, og det er slik en klientnøkkel havner i et offentlig arkiv. Å skille ut hvilken blokk som gjør hva forklarer det meste av forvirringen rundt disse profilene, og det forteller deg også hvilke feil du må rette selv.

Én fil, tre blokker, ulike oppgaver

En typisk profil bygger inn en ca-blokk, en cert-blokk og en key-blokk mellom BEGIN- og END-markørene, eller peker på de samme tre som separate filer. Noen profiler legger til en fjerde blokk for en tls-auth- eller tls-crypt-nøkkel, som er en delt hemmelighet og ikke et sertifikat. Klienten leser hver blokk etter direktivet som navngir den, så etikettene betyr mer enn rekkefølgen de opptrer i.

Behandle den sammensatte profilen som følsom til du faktisk har sett inni den. Et offentlig sertifikat og en privat nøkkel kan ligge noen få linjer fra hverandre i samme fil, og et skjermbilde som tar med overskriften kan inneholde begge. Å sladde den synlige base64 for hånd er også upålitelig, fordi en delvis blokk fortsatt lekker sertifikatmetadataene som navngir utrullingen din. Å kopiere de tre direktivene uten verdiene deres er vanligvis nok til å stille et nyttig spørsmål.

Direktivene rundt blokkene avgjør hvordan de brukes. Endre ca og klienten stoler på en annen myndighet; endre cert uten å endre key og håndtrykket feiler med et avvik som ikke har noe med tillit å gjøre.

CA-blokken er offentlig, CA-nøkkelen aldri

En sertifikatmyndighet signerer sertifikater som binder en offentlig nøkkel til en identitet, og dens eget sertifikat er ankeret en klient bruker for å avgjøre om en kjede er til å stole på. Det sertifikatet er offentlig av design: å sende det inne i hver profil er normalt, og det er grunnen til at en selvsignert utrulling kan fungere uten en kommersiell myndighet.

Det som aldri må forekomme i en klientprofil, er myndighetens private signeringsnøkkel. Klienten trenger den ikke for å validere noe, og dens tilstedeværelse betyr at den som har profilen kan lage nye identiteter for hele utrullingen.

Å stole på en myndighet er også smalere enn det høres ut. En klient som godtar ethvert sertifikat signert av CA-en, godtar fortsatt et sertifikat utstedt for en annen tjeneste på samme CA. Alternativer som fester forventet serverrolle eller -navn, lukker det gapet, og TLS-alternativreferansen lister opp verifiseringsdirektivene som gjør det.

Server- og klientsertifikater peker i motsatte retninger

Serverens sertifikat er det klienten undersøker for å bekrefte at den nådde riktig endepunkt. Klientsertifikatet ditt går motsatt vei: serveren bruker det for å avgjøre at denne enheten eller brukeren er en den har registrert. Samme format, motsatt tillitsretning.

En adresse er ikke en identitet. Å nå riktig IP beviser ingenting om hvem som svarte, derfor hører kontroll av vertsnavn eller sertifikatnavn fortsatt hjemme i profilen. Et kontopassord erstatter heller ikke et påkrevd klientsertifikat i det stille, fordi de to kontrolleres på ulike stadier og en utrulling kan kreve begge.

Klientens private nøkkel er den delen som må forbli privat. Hvis den kan ha blitt avslørt, endrer sletting av filen på laptopen ingenting på serveren, som vil fortsette å godta det tilsvarende sertifikatet til operatøren tilbakekaller det. Å be operatøren erstatte eller tilbakekalle den identiteten er den eneste løsningen som reiser med deg.

To forespørsler som ser identiske ut og ikke er det

En nøkkel som er lagret i kryptert form, ber om en passfrase før klienten kan bruke den. VPN-tjenesten kan be om et kontopassord separat, og de to forespørslene kan komme sekunder fra hverandre med nesten samme ordlyd. Passfrasen beskytter en fil på disken din; passordet beviser en konto overfor en server. Å blande dem sender folk til tilbakestillinger som umulig kan hjelpe.

Les forespørselen før du tilbakestiller noe. En tilbakestilling av kontopassordet gjør ingenting for en glemt nøkkelpassfrase, et tilbakekalt eller utløpt sertifikat, og å tilbakestille passordet når feilen er sertifikatvalidering gjør en to-minutters rettelse til en støttesak. Hvis klagen nevner gyldighetsdatoer, sjekk enhetens klokke først og deretter det navngitte sertifikatets eget vindu.

Når sertifikatet virkelig er utløpt, må erstatningen komme fra den som utstedte det. En nøkkel som tilhører noen andre, er ikke en fornyelsesvei, og det er heller ikke å låne en fungerende profil fra en kollega.

Hva et rent håndtrykk beviser og hva det ikke beviser

Å nå et fullført TLS-håndtrykk betyr at det konfigurerte identitetsforholdet holdt: serverens sertifikat kjedes til CA-en din, og sertifikatet ditt ble godtatt. Det sier ingenting om operatørens loggføringspolicy, og ingenting om hvorvidt applikasjonene dine vil fungere når tunnelen er oppe.

Ruter og DNS er senere stadier av forbindelsen, så en utilgjengelig intranettvert etter vellykket pålogging er et tilkoblingsproblem og ikke et sertifikatproblem. Arbeid på det laget i stedet for å bytte påloggingsinformasjon, og hold profilens opphav, dens private materiale og dens identitetskontroller sammen når du gir den til noen.