Brug din eksisterende virksomheds-CA til OpenVPN-peers

Intet i OpenVPN kræver, at certifikatet kommer fra Easy-RSA, og en flåde, der allerede har en organisatorisk PKI, bør normalt ikke bygge en anden. Det egentlige arbejde er ikke at vælge et værktøj, men at beslutte, hvad de udstedte identiteter betyder, hvilke peers tunnelen accepterer, og hvordan fornyelse og tilbagekaldelse når verifikatoren. Gå gennem de fem trin nedenfor i rækkefølge, fordi et senere trin ikke kan reparere en rollebeslutning truffet i det første.

Udsted to roller i stedet for én delt identitet

Hver peer har brug for sit eget certifikat og en matchende privat nøgle. Bed PKI-teamet om en serveridentitet med serverbrug og separate klientidentiteter med klientbrug, så tunnelen kan skelne de to ved håndtrykket.

Modstå de genveje, der dukker op under deadlinepres. En webservers nøgle kopieret til laptops sletter den forskel, som rollekontrollen afhænger af, og en CA-signeringsnøgle installeret på et VPN-endepunkt gør én kompromitteret vært til en kompromitteret hierarki. En PKCS12-pakke kan bære en endepunktsnøgle og dens kæde, men den giver aldrig tilladelse til at genbruge den identitet i en anden rolle.

Tilslut tillidsinput på hver side

Klienten og serveren har hver især brug for et tillidsanker, deres egen identitet og en eksplicit rolleforventning. Et klientuddrag, der angiver alle tre, ser sådan ud.

client
ca /etc/openvpn/pki/issuing-root.pem
cert /etc/openvpn/pki/device-17.crt
key /etc/openvpn/pki/device-17.key
remote-cert-tls server
verify-x509-name vpn.corp.example name
crl-verify /etc/openvpn/pki/issuing.crl

Serversiden spejler det med remote-cert-tls client og sit eget certifikat, og det er det, der forhindrer, at et klientcertifikat accepteres som server. Navnekontrollen er en beslutning adskilt fra rollekontrollen. Læs den udrullede konfiguration for at se, hvilket felt der sammenlignes, i stedet for at antage et browsertypisk værtsnavnmatch. Begge sider bør også være eksplicitte om, hvilken udsteder de stoler på, fordi en delt filsti på tværs af flåden ikke er det samme som en delt politik.

Lever intermediære certifikater uden at udvide tilliden

De to sider behøver ikke dele én udstedelseskæde. Når en peer præsenterer et certifikat signeret af en intermediær, har den verificerende side brug for den intermediære tilgængelig, og OpenVPN skelner mellem tillidsankerinputtet og de ekstra certifikater, der bruges til at fuldføre en lokalt præsenteret kæde. TLS-indstillingsreferencen for OpenVPN 2.6 dokumenterer begge.

En intermediær CA er ikke i sig selv et problem, men en bred virksomhedsrod smidt i tillidsbundtet er. Jo bredere ankeret er, jo flere certifikater består kædetesten, og en rollekontrol gør ikke det til en liste over autoriserede medarbejdere. Indsnævr ankeret til den udsteder, der faktisk signerer VPN-identiteter, hvor hierarkiet tillader det. Hvis ikke, dokumentér det bredere anker som en bevidst accepteret risiko i stedet for at lade det være implicit.

Aftal med PKI-teamet, hvordan fornyelse og tilbagekaldelse når VPN-verifikatorerne, herunder hvilke udstedere der betyder noget, og hvem der offentliggør listen. Et CRL-distributionspunkt indlejret i et certifikat er en instruktion, ikke bevis for, at noget hentede det.

Beslut, hvordan tilbagekaldelse faktisk ankommer

crl-verify får verifikatoren til at konsultere en fil eller et endepunkt, og den ordning har brug for en ejer og en opdateringssti. En liste, der kopieres én gang under udrulningen, holder stille op med at beskytte dig, første gang et certifikat tilbagekaldes.

Skriv den forventede spredningstid ned, og test den med et certifikat, du er villig til at tilbagekalde. Hvis listen ikke kan opdateres på VPN-værten, er alternativet en kortere gyldighedsperiode plus en fornyelsesproces, der faktisk kører, ikke en antagelse om, at tilbagekaldelse virker, fordi der findes en URL.

Bevis accept med en rigtig klient

Forbind en klient, der bør tillades, og bekræft de forhandlede certifikatoplysninger i loggen. Prøv derefter de tilfælde, der skal fejle: et klientcertifikat præsenteret som server, et certifikat fra en udsteder uden for tillidsankeret og et tilbagekaldt certifikat, hvis du har et i overskud.

Registrér den accepterede udsteder, rollekontrollen og tilbagekaldelseskilden ved siden af profilen. Den registrering er, hvad den næste ingeniør har brug for, når en enhed, der virkede sidste måned, holder op med at oprette forbindelse, og det er også beviset for, at virksomheds-CA'en bruges inden for en dokumenteret acceptgrænse i stedet for som et tillidsdump til almindelige formål.