Använd din befintliga företags-CA för OpenVPN-peers

Ingenting i OpenVPN kräver att certifikatet kommer från Easy-RSA, och en flotta som redan har en organisatorisk PKI bör vanligtvis inte bygga en till. Det egentliga arbetet är inte att välja ett verktyg, utan att avgöra vad de utfärdade identiteterna betyder, vilka peers tunneln accepterar och hur förnyelse och återkallelse når verifieraren. Gå igenom de fem stegen nedan i ordning, eftersom ett senare steg inte kan reparera ett rollbeslut som fattats i det första.

Utfärda två roller i stället för en delad identitet

Varje peer behöver sitt eget certifikat och en matchande privat nyckel. Be PKI-teamet om en serveridentitet med serveranvändning och separata klientidentiteter med klientanvändning, så att tunneln kan skilja de två åt vid handskakningen.

Stå emot genvägarna som dyker upp under deadlinepress. En webbservers nyckel kopierad till bärbara datorer raderar den skillnad som rollkontrollen bygger på, och en CA-signeringsnyckel installerad på en VPN-slutpunkt gör en komprometterad värd till en komprometterad hierarki. Ett PKCS12-paket kan bära en slutpunktsnyckel och dess kedja, men det ger aldrig tillstånd att återanvända den identiteten i en annan roll.

Koppla in förtroendeingångarna på varje sida

Klienten och servern behöver var sin förtroendeankare, egen identitet och en uttrycklig rollförväntan. Ett klientutdrag som anger alla tre ser ut så här.

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

Serversidan speglar det med remote-cert-tls client och sitt eget certifikat, och det är detta som hindrar ett klientcertifikat från att accepteras som server. Namnkontrollen är ett beslut skilt från rollkontrollen. Läs den utrullade konfigurationen för att se vilket fält som jämförs i stället för att anta en webbläsarlik värdnamnsmatchning. Båda sidor bör också vara tydliga med vilken utfärdare de litar på, eftersom en delad filsökväg i flottan inte är samma sak som en delad policy.

Leverera mellanliggande certifikat utan att bredda förtroendet

De två sidorna behöver inte dela en enda utfärdarkedja. När en peer presenterar ett certifikat signerat av en mellanliggande CA behöver den verifierande sidan den mellanliggande CA:n tillgänglig, och OpenVPN skiljer förtroendeankarets ingång från de extra certifikat som används för att fullborda en lokalt presenterad kedja. TLS-alternativreferensen för OpenVPN 2.6 dokumenterar båda.

En mellanliggande CA är inte i sig ett problem, men en bred företagsrot som slängs i förtroendepaketet är det. Ju bredare ankaret är, desto fler certifikat klarar kedjetestet, och en rollkontroll gör inte det till en lista över behörig personal. Begränsa ankaret till den utfärdare som faktiskt signerar VPN-identiteter där hierarkin tillåter det. Om inte, dokumentera det bredare ankaret som en medvetet accepterad risk i stället för att lämna det implicit.

Kom överens med PKI-teamet om hur förnyelse och återkallelse når VPN-verifierarna, inklusive vilka utfärdare som spelar roll och vem som publicerar listan. En CRL-distributionspunkt inbäddad i ett certifikat är en instruktion, inte bevis på att något hämtade den.

Bestäm hur återkallelse faktiskt anländer

crl-verify får verifieraren att konsultera en fil eller slutpunkt, och det arrangemanget behöver en ägare och en uppdateringsväg. En lista som kopieras en gång vid utrullningen slutar tyst att skydda dig första gången ett certifikat återkallas.

Skriv ned den förväntade spridningstiden och testa den med ett certifikat du är beredd att återkalla. Om listan inte kan uppdateras på VPN-värden är alternativet en kortare giltighetstid plus en förnyelseprocess som faktiskt kör, inte ett antagande att återkallelse fungerar för att det finns en URL.

Bevisa acceptansen med en riktig klient

Anslut en klient som bör tillåtas och bekräfta de förhandlade certifikatuppgifterna i loggen. Prova sedan fallen som måste misslyckas: ett klientcertifikat presenterat som server, ett certifikat från en utfärdare utanför förtroendeankaret och ett återkallat certifikat om du har ett över.

Registrera den accepterade utfärdaren, rollkontrollen och återkallelsekällan bredvid profilen. Den registreringen är vad nästa ingenjör behöver när en enhet som fungerade förra månaden slutar ansluta, och det är också beviset för att företags-CA:n används inom en dokumenterad acceptansgräns i stället för som en förtroendedeponi för allmänna ändamål.