Hoe't jo in ferâldere VPN-sertifikaat út in fertrouwensopslach ferwiderje

Jo VPN-klant is de-ynstallearre, it profyl is fuort út Ynstellingen, en de tunnel komt noch altyd op mei de âlde oanmeldgegevens. Of jo wiskje it, starte opnij, en fine it de folgjende moarns werom. Net ien fan beide is in stikken wiskknop. In profyl is konfiguraasje; in sertifikaat is kaaimateriaal plus in fertrouwensbeslissing dy't fêstlein is yn in opslach dêr't it profyl allinnich nei wiist. Hokker fan de twa jo hâlde, beslút wat 'ferwiderje' betsjutte moat.

In profyl is gjin sertifikaat

Trije ferskillende objekten hjitte 'it sertifikaat' yn in VPN-ynstelling. De kliïntidentiteit is in einblêdsertifikaat mei in partikuliere kaai, en de gateway brûkt it om te besluten wa't jo binne. It eigen einblêd fan 'e tsjinner en syn tuskenlizzende sertifikaat binne wat jo klant kontrolearret as it ferbynt. De fertrouwensanker, meastentiids in woartel- of partikulier CA-sertifikaat, is wat de keatling hielendal ferifiearber makket. RFC 5280 neamt dizze fertrouwensanker, tuskenlizzend sertifikaat en einentiteit, en de keatling falidearret allinnich salang't elke skakel dy't derûnder leit ûndertekent.

Wiskje de identiteit en ien apparaat ferliest tagong. Wiskje de anker en elke applikaasje dy't tsjin dy opslach falidearret ferliest it fermogen om wat dan ek te kontrolearjen dat dêrûnder útjûn is, ynklusyf ferbiningen dy't neat mei de VPN te krijen hawwe. Dy asymmetry is it hiele risiko hjir: in woartel ynstallearre foar ien gateway is faak deselde woartel dy't in ynterne portal, in mailtsjinner of in pakketspiegel ûndertekenet. Tink derom hokker fan de twa jo hâlde.

Eigendom beslút oft it wiskjen wiske bliuwt. Op in laptop dy't jo besitte, binne jo de iennige dy't it sertifikaat werom sette kin. Op in beheard apparaat kin in konfiguraasjeprofyl of in MDM-payload it by de folgjende registraasje wer ynstallearje, en dêrom 'komt it werom' en dêrom helpt hurder wiskjen net.

Fyn út hokker opslach it noch hat

Minsken begjinne yn 'e Ynstellingen-app, dat is it iene plak dêr't in sertifikaat net bewarre wurdt. De echte lokaasjes binne de fertrouwensopslaggen fan it bestjoeringssysteem, de eigen opslach fan 'e browser en de partikuliere opslach fan 'e applikaasje.

Ferlykje op it searjenûmer of de fingerôfdruk, nea op 'e werjefte namme. Werjefte nammen wurde set troch wa't it sertifikaat útjûn hat en wurde opnij brûkt: 'Example VPN' kinne trije sertifikaten mei trije ferskillende kaaien wêze, ien noch yn deistich gebrûk.

certutil -user -store My
certutil -store Root
openssl x509 -in vpn-client.pem -noout -subject -issuer -serial -fingerprint -sha256

Op macOS jout it security-ark deselde feiten, en find-identity lit sjen hokker sertifikaten noch in partikuliere kaai ferbûn hawwe:

security find-certificate -a -c "Example VPN" -Z /Library/Keychains/System.keychain
security find-identity -v -p ssl-client

Wiskje it smelle objekt, hâld de dielde útjouwer

Eksportearje foardat jo wiskje. Sûnder reservekopy is it iennige herstel opnij útjaan, wat op in partikulier CA betsjut weromgean nei wa't de PKI beheart. De eksportearre PFX is ek wat jo oerhandigje as it ferwiderjen de ferkearde beslissing blykt.

certutil -user -exportPFX -p backup My <serial> C:\temp\vpn-id.pfx
certutil -user -delstore My <serial>
Remove-Item Cert:\CurrentUser\My<thumbprint>

It -user -flag is dejinge dy't minsken by ûngelok falle litte. Sûnder it wurket certutil op 'e masineopslach ynstee, wat in ferhege shell, in oare set sertifikaten en in ynfloedsradius betsjut dy't no elk oar akkount op 'e masine omfettet.

Op macOS en Linux is de foarm itselde: identifisearje, eksportearje, ferwiderje dan út 'e smelste opslach dy't it symptoom ferklearret. It bestân ûnder /usr/local/share/ca-certificates ferwiderje en update-ca-certificates wer opnij rinne litte is genôch; --fresh helpt allinnich as de symlinks yn /etc/ssl/certs al ynkonsistint binne. RHEL-famyljesystemen hâlde ankers yn /etc/pki/ca-trust/source/anchors, dêr't trust anchor --remove itselde wurk docht.

sudo security delete-certificate -Z <sha1> /Library/Keychains/System.keychain
sudo rm /usr/local/share/ca-certificates/example-vpn.crt
sudo update-ca-certificates
sudo trust anchor --remove /etc/pki/ca-trust/source/anchors/example-vpn.crt

Kontrolearje foardat jo in CA-sertifikaat wiskje wat der noch mear oan keatlinget. De ûnderwerpen yn 'e bondel opsomme is in kontrôle yn twa rigels en it antwurdet oft dy anker oar wurk docht:

openssl crl2pkcs7 -nocrl -certfile /etc/ssl/certs/ca-certificates.crt \
  | openssl pkcs7 -print_certs -noout | grep -i example

It bestân wiskje is net de identiteit yntrekke

In lokaal wiskjen ferwidert ien kopy. De partikuliere kaai kin noch sitte yn in p12 ferbûn oan in âld ticket, in reservekopy-map of de twadde laptop dy't tagelyk opset is. As dit in kliïntidentiteit wie, bliuwt de gateway elke kopy fan dy kaai akseptearjen oant de identiteit oan 'e tsjinnerkant wegere wurdt.

Foar in OpenVPN PKI betsjut dat it sertifikaat yntrekke en derfoar soargje dat de CRL dêr't crl-verify nei ferwiist aktueel is; easyrsa revoke dan easyrsa gen-crl is de koarte ferzje. Foar in gateway ferbûn oan in identiteitsleveransier, skeakelje de brûker dêr út of ferwiderje it apparaat, want it sertifikaat is mar ien oanmeldgegevens yn it spul. De lokale kopy wiskje wylst it akkount aktyf bliuwt liket op opromjen en is dat net.

Ynsidintwurk hat in oare folchoarder: bewarje earst it sertifikaat, syn searjenûmer en it yntrekkingsregister, wiskje en yntrek dan. Dy registers kostje neat en fereaskje net dat in wurkjende oanmeldgegevens bliuwt stean.

Ferifiearje mei in hânskodding en in twadde app

Kontrolearje de keatling fan bûten, net fan 'e opslachlist dy't jo krekt bewurke hawwe. De opslach lit jo bewurking sjen; de hânskodding lit it resultaat sjen.

openssl s_client -connect vpn.example.com:443 -servername vpn.example.com \
  -CAfile /etc/ssl/certs/ca-certificates.crt -verify_return_error < /dev/null
openssl verify -CAfile /etc/ssl/certs/ca-certificates.crt vpn-gateway.pem

In weromjeftekode fan 0 betsjut dat de oerbleaune ankers de gateway noch falidearje. In keatlingflater nei it ferwiderjen fan 'e anker is de ferwachte útkomst, en it befêstiget dat jo de anker rekke hawwe dy't yn gebrûk is, net in duplikaat yn in opslach dy't de klant nea lêst. As de ferbining noch wurket, sykje dan in twadde kopy, in opslach boud yn 'e app of in fêstset sertifikaat, allegear gewoan yn klanten dy't har eigen fertrouwenslist leverje.

Test dan wat net besibbe is: in ynterne side, in mailklant, in pakketspiegel. Dat mjit de ynfloedsradius goedkeap, foardat it feroaringsfinster slút.

• Rol identifisearre as identiteit, tuskenlizzend sertifikaat of fertrouwensanker
• Searjenûmer en fingerôfdruk fêstlein, en de kopy eksportearre nei de goedkarde lokaasje
• Wiskjen dien yn 'e smelste omfang dy't it symptoom ferklearret
• Tsjinnerkant-autorisaasje yntrokken doe't in persoan of apparaat fuortgie
• Hânskodding ferklearre, en ien net besibbe app opnij test
• MDM-payload of behearprofyl bywurke, oars komt it sertifikaat werom

As it sertifikaat nei in opnij starten werom is, is it wurk net dien: eat besit it en ynstallearret it opnij. Fyn dy eigener foardat jo wer wiskje, want in tredde wiskjen sil him krekt sa gedrage as de earste twa.