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

Du åbner en .ovpn-fil for at ændre én linje og finder tre blokke base64, der alle ser ud som legitimationsoplysninger. Én er sikker at offentliggøre, én er lige så følsom som en adgangskode, og én er en offentlig nøgle, der ikke betyder noget, medmindre noget andet er signeret med dens makker. Folk indsætter hele filen i en supporttråd, fordi blokkene ser ud til at kunne byttes, og det er sådan en klientnøgle ender i et offentligt arkiv. At skelne hvilken blok der gør hvad forklarer det meste af forvirringen omkring disse profiler og fortæller dig også, hvilke fejl der er dine at rette.

Én fil, tre blokke, forskellige opgaver

En typisk profil indlejrer en ca-blok, en cert-blok og en key-blok mellem BEGIN- og END-markører eller peger på de samme tre som separate filer. Nogle profiler tilføjer en fjerde blok til en tls-auth- eller tls-crypt-nøgle, som er en fælles hemmelighed og ikke et certifikat. Klienten læser hver blok efter den direktiv, der navngiver den, så etiketterne betyder mere end rækkefølgen, de optræder i.

Behandl den samlede profil som følsom, indtil du faktisk har set indeni. Et offentligt certifikat og en privat nøgle kan ligge få linjer fra hinanden i samme fil, og et skærmbillede, der omfatter headeren, kan omfatte begge. At sløre det synlige base64 i hånden er også upålideligt, fordi en delvis blok stadig lækker de certifikatmetadata, der navngiver din udrulning. At kopiere de tre direktiver uden deres værdier er normalt nok til at stille et brugbart spørgsmål.

Direktiverne omkring blokkene afgør, hvordan de bruges. Skift ca, og klienten stoler på en anden myndighed; skift cert uden at skifte key, og håndtrykket fejler med en uoverensstemmelse, der intet har med tillid at gøre.

CA-blokken er offentlig, CA-nøglen aldrig

En certifikatmyndighed signerer certifikater, der binder en offentlig nøgle til en identitet, og dens eget certifikat er det anker, en klient bruger til at afgøre, om en kæde er troværdig. Det certifikat er offentligt af design: at sende det inde i hver profil er normalt, og det er grunden til, at en selvsigneret udrulning kan fungere uden en kommerciel myndighed.

Det, der aldrig må optræde i en klientprofil, er myndighedens private signeringsnøgle. Klienten har ikke brug for den til at validere noget, og dens tilstedeværelse betyder, at enhver, der har profilen, kan præge nye identiteter til hele udrulningen.

At stole på en myndighed er også snævrere, end det lyder. En klient, der accepterer ethvert certifikat signeret af CA'en, accepterer stadig et certifikat udstedt til en anden tjeneste på samme CA. Valgmuligheder, der fastlåser den forventede serverrolle eller -navn, lukker det hul, og TLS-valgmulighedsreference viser de verifikationsdirektiver, der gør det.

Server- og klientcertifikater peger i modsatte retninger

Serverens certifikat er det, klienten undersøger for at bekræfte, at den nåede det rigtige endepunkt. Dit klientcertifikat går den anden vej: serveren bruger det til at afgøre, at denne enhed eller bruger er en, den har indskrevet. Samme format, modsat tillidsretning.

En adresse er ikke en identitet. At nå den rigtige IP beviser intet om, hvem der svarede, og derfor hører kontrol af værtsnavn eller certifikatnavn stadig til i profilen. En kontoadgangskode erstatter heller ikke stille et krævet klientcertifikat, fordi de to kontrolleres på forskellige stadier, og en udrulning kan kræve begge.

Klientens private nøgle er den del, der skal forblive privat. Hvis den kan være blevet afsløret, ændrer sletning af filen på din bærbare intet på serveren, som vil blive ved med at acceptere det tilsvarende certifikat, indtil operatøren tilbagekalder det. At bede operatøren om at erstatte eller tilbagekalde den identitet er den eneste løsning, der rejser med dig.

To forespørgsler, der ser identiske ud og ikke er det

En nøgle gemt i krypteret form beder om en adgangsfrase, før klienten kan bruge den. VPN-tjenesten kan separat bede om en kontoadgangskode, og de to forespørgsler kan komme sekunder fra hinanden med næsten samme ordlyd. Adgangsfrasen beskytter en fil på din disk; adgangskoden beviser en konto over for en server. At forveksle dem sender folk til nulstillinger, der umuligt kan hjælpe.

Læs forespørgslen, før du nulstiller noget. En nulstilling af kontoadgangskoden gør intet for en glemt nøglefrase, et tilbagekaldt eller et udløbet certifikat, og at nulstille adgangskoden, når fejlen er certifikatvalidering, gør en to-minutters rettelse til en supportssag. Hvis klagen nævner gyldighedsdatoer, så tjek enhedens ur først og derefter det navngivne certifikats eget vindue.

Når certifikatet virkelig er udløbet, skal erstatningen komme fra dem, der udstedte det. En nøgle, der tilhører en anden, er ikke en fornyelsesvej, og det er at låne en fungerende profil fra en kollega heller ikke.

Hvad et rent håndtryk beviser, og hvad det ikke gør

At nå et fuldført TLS-håndtryk betyder, at det konfigurerede identitetsforhold holdt: serverens certifikat kædede til din CA, og dit certifikat blev accepteret. Det siger intet om operatørens logningspolitik og intet om, hvorvidt dine applikationer vil fungere, når tunnelen er oppe.

Ruter og DNS er senere stadier af forbindelsen, så en utilgængelig intranetvært efter et vellykket login er et forbindelsesproblem og ikke et certifikatproblem. Arbejd på det lag i stedet for at bytte legitimationsoplysninger, og hold profilens oprindelse, dens private materiale og dens identitetskontroller sammen, når du giver den til nogen.