Gebruik uw bestaande bedrijfs-CA voor OpenVPN-peers

Niets in OpenVPN vereist dat het certificaat van Easy-RSA komt, en een vloot die al een organisatorische PKI heeft, zou normaal gesproken geen tweede moeten bouwen. Het echte werk is niet een hulpmiddel kiezen, maar beslissen wat de uitgegeven identiteiten betekenen, welke peers de tunnel accepteert en hoe vernieuwing en intrekking bij de verificateur aankomen. Doorloop de vijf stappen hieronder in volgorde, want een latere stap kan een rolbeslissing uit de eerste niet repareren.

Geef twee rollen uit in plaats van één gedeelde identiteit

Elke peer heeft zijn eigen certificaat en bijbehorende privésleutel nodig. Vraag het PKI-team om een serveridentiteit met servergebruik en afzonderlijke clientidentiteiten met clientgebruik, zodat de tunnel de twee tijdens de handshake kan onderscheiden.

Weersta de snelkoppelingen die onder deadlinedruk opduiken. Een sleutel van een webserver die naar laptops wordt gekopieerd, wist het onderscheid waarop de rolcontrole berust, en een CA-ondertekeningssleutel die op een VPN-eindpunt wordt geïnstalleerd, maakt van één gecompromitteerde host een gecompromitteerde hiërarchie. Een PKCS12-bundel kan een eindpuntsleutel en zijn keten dragen, maar geeft nooit toestemming om die identiteit in een andere rol te hergebruiken.

Sluit de vertrouwensinvoer aan elke kant aan

De client en de server hebben elk een vertrouwensanker, hun eigen identiteit en een expliciete rolverwachting nodig. Een clientfragment dat alle drie vermeldt, ziet er zo uit.

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

De serverzijde spiegelt dat met remote-cert-tls client en zijn eigen certificaat, en dat is wat voorkomt dat een clientcertificaat als server wordt geaccepteerd. De naamcontrole is een aparte beslissing van de rolcontrole. Lees de uitgerolde configuratie om te zien welk veld wordt vergeleken in plaats van een browserachtige hostnaamovereenkomst aan te nemen. Beide kanten moeten ook expliciet zijn over welke uitgever ze vertrouwen, want een gedeeld bestandspad in de vloot is niet hetzelfde als een gedeeld beleid.

Lever tussenliggende certificaten zonder het vertrouwen te verbreden

De twee kanten hoeven geen enkele uitgifteketen te delen. Wanneer een peer een certificaat presenteert dat door een tussenliggende CA is ondertekend, heeft de verifiërende kant die tussenliggende CA beschikbaar nodig, en OpenVPN onderscheidt de invoer van het vertrouwensanker van de extra certificaten die worden gebruikt om een lokaal gepresenteerde keten te voltooien. De TLS-optiereferentie van OpenVPN 2.6 documenteert beide.

Een tussenliggende CA is op zichzelf geen probleem, maar een brede bedrijfswortel in de vertrouwensbundel is dat wel. Hoe breder het anker, hoe meer certificaten de ketentest doorstaan, en een rolcontrole maakt daar geen lijst van bevoegde medewerkers van. Vernauw het anker tot de uitgever die daadwerkelijk VPN-identiteiten ondertekent waar de hiërarchie dat toelaat. Als dat niet kan, documenteer het bredere anker dan als een bewust geaccepteerd risico in plaats van het impliciet te laten.

Spreek met het PKI-team af hoe vernieuwing en intrekking de VPN-verificateurs bereiken, inclusief welke uitgevers ertoe doen en wie de lijst publiceert. Een CRL-distributiepunt in een certificaat is een instructie, geen bewijs dat iets het heeft opgehaald.

Bepaal hoe intrekking daadwerkelijk aankomt

crl-verify zorgt ervoor dat de verificateur een bestand of eindpunt raadpleegt, en die regeling heeft een eigenaar en een vernieuwingspad nodig. Een lijst die tijdens de uitrol één keer wordt gekopieerd, stopt stilletjes met u beschermen zodra een certificaat wordt ingetrokken.

Noteer de verwachte verspreidingstijd en test die met een certificaat dat u bereid bent in te trekken. Als de lijst niet kan worden vernieuwd op de VPN-host, is het alternatief een kortere geldigheidsduur plus een vernieuwingsproces dat echt draait, niet de aanname dat intrekking werkt omdat er een URL bestaat.

Bewijs de acceptatie met een echte client

Verbind een client die toegestaan moet worden en bevestig de onderhandelde certificaatgegevens in het log. Probeer daarna de gevallen die moeten mislukken: een clientcertificaat dat als server wordt gepresenteerd, een certificaat van een uitgever buiten het vertrouwensanker, en een ingetrokken certificaat als u er een over heeft.

Leg de geaccepteerde uitgever, de rolcontrole en de intrekkingsbron naast het profiel vast. Die registratie is wat de volgende ingenieur nodig heeft wanneer een apparaat dat vorige maand werkte stopt met verbinden, en het is ook het bewijs dat de bedrijfs-CA binnen een gedocumenteerde acceptatiegrens wordt gebruikt en niet als een vertrouwensdump voor algemeen gebruik.