Brûk jo besteande ûndernimmings-CA foar OpenVPN-peers

Neats yn OpenVPN freget dat it sertifikaat fan Easy-RSA komt, en in float dy't al in organisatoaryske PKI hat, soe normaal gjin twadde bouwe moatte. It echte wurk is net it kiezen fan in helpmiddel, mar it besluten wat de útjûne identiteiten betsjutte, hokker peers de tunnel akseptearret en hoe't fernijing en ynlûking by de ferifiearder komme. Wurkje de fiif stappen hjirûnder yn folchoarder troch, want in lettere stap kin in rolbeslissing dy't yn 'e earste nommen is net reparearje.

Jou twa rollen út ynstee fan ien dielde identiteit

Elke peer hat syn eigen sertifikaat en byhearrende priveesleutel nedich. Freegje it PKI-team om in serveridentiteit mei servergebrûk en aparte kliïntidentiteiten mei kliïntgebrûk, sadat de tunnel de twa by de hânskudding ûnderskiede kin.

Wjerstean de flugge wei dy't ûnder deadline-druk opkomt. In webserversleutel dy't op laptops kopiearre wurdt, wisket it ûnderskie dêr't de rolkontrôle op stipet, en in CA-ûndertekeningssleutel dy't op in VPN-einpunt ynstallearre is, makket fan ien kompromittearre gasthear in kompromittearre hiërargy. In PKCS12-pakket kin in einpuntsleutel en syn keatling drage, mar it jout nea tastimming om dy identiteit yn in oare rol wer te brûken.

Ferbin de fertrouwensynfier oan elke kant

De kliïnt en de server hawwe elk in fertrouwensanker, har eigen identiteit en in eksplisite rolferwachting nedich. In kliïntfragmint dat alle trije neamt, sjocht der sa út.

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 serverkant spegelet dat mei remote-cert-tls client en syn eigen sertifikaat, en dat is wat foarkomt dat in kliïntsertifikaat as server akseptearre wurdt. De namkontrol is in apart beslút fan 'e rolkontrôle. Lês de útrôle konfiguraasje om te sjen hokker fjild ferlike wurdt, ynstee fan in hostnamematch op browserwize oan te nimmen. Beide kanten moatte ek eksplisyt wêze oer hokker útjouwer se fertrouwe, want in dielde bestânspaad oer de float is net itselde ding as in dield belied.

Leverje tuskenlizzende sertifikaten sûnder fertrouwen te ferbreedzjen

De twa kanten hoegve net ien útjaan-keatling te dielen. As in peer in sertifikaat oanbiedt dat troch in tuskenlizzende ûndertekene is, hat de ferifiearjende kant dy tuskenlizzende beskikber nedich, en OpenVPN ûnderskiedt de fertrouwensanker-ynfier fan de ekstra sertifikaten dy't brûkt wurde om in lokaal oanbean keatling te foltôgjen. De TLS-opsjeferwizing fan OpenVPN 2.6 dokumintearret beide.

In tuskenlizzende CA is op himsels gjin probleem, mar in brede ûndernimmingswoartel dy't yn 'e fertrouwensbondel smiten wurdt, is dat wol. Hoe breder it anker, hoe mear sertifikaten de keatlingtest trochsteane, en in rolkontrôle makket dêr gjin list fan autorisearre personiel fan. Fernau it anker ta de útjouwer dy't feitlik VPN-identiteiten ûndertekenet, wêr't de hiërargy it tastiet. Doet it dat net, dokumintearje dan it bredere anker as in bewust akseptearre risiko ynstee fan it ymplisyt te litten.

Kom oerien mei it PKI-team oer hoe't fernijing en ynlûking by de VPN-ferifiearders komme, ynklusyf hokker útjouwers der ta dogge en wa't de list publisearret. In CRL-ferspriedingspunt dat yn in sertifikaat ynbêde is, is in oanwizing, gjin bewiis dat immen it ophelle hat.

Beslút hoe't ynlûking feitlik oankomt

crl-verify lit de ferifiearder in bestân of einpunt rieplachtsje, en dy regeling hat in eigner en in ferfarskingspaad nedich. In list dy't ien kear by de útrôling kopiearre wurdt, hâldt stilwei op mei jo te beskermjen de earste kear dat in sertifikaat ynlutsen wurdt.

Skriuw de ferwachte ferspriedingstiid op en test dy mei in sertifikaat dat jo beried binne yn te lûken. Kin de list net ferfarske wurde op de VPN-gasthear, dan is it alternatyf in koartere jildichheidsperioade plus in fernijingsproses dat feitlik rint, net in oanname dat ynlûking wurket om't der in URL bestiet.

Bewiis akseptaasje mei in echte kliïnt

Ferbin in kliïnt dy't tastien wurde moat en befêstigje de ûnderhannele sertifikaatdetails yn it log. Probearje dan de gefallen dy't mislearje moatte: in kliïntsertifikaat dat as server oanbean wurdt, in sertifikaat fan in útjouwer bûten it fertrouwensanker, en in ynlutsen sertifikaat as jo der ien oer hawwe.

Registrearje de akseptearre útjouwer, de rolkontrôle en de boarne fan ynlûking njonken it profyl. Dat register is wat de folgjende yngenieur nedich hat as in apparaat dat ferline moanne wurke, ophâldt mei ferbinen, en it is ek it bewiis dat de ûndernimmings-CA brûkt wurdt binnen in dokumintearre akseptaasjegrins ynstee fan as in fertrouwensdumpsite foar algemien gebrûk.