Hogyan távolítsunk el egy elavult VPN-tanúsítványt egy megbízhatósági tárolóból

A VPN-ügyfél el van távolítva, a profil eltűnt a Beállításokból, a alagút mégis a régi hitelesítő adatokkal jön fel. Vagy törli, újraindítja, és másnap reggel visszatalálja. Egyik sem hibás törlésgomb. A profil konfiguráció; a tanúsítvány kulcsanyag plusz egy bizalmi döntés, amelyet olyan tároló rögzít, amelyre a profil csak hivatkozik. Hogy melyik van a kezében, eldönti, mit kell jelentenie az 'eltávolításnak'.

A profil nem tanúsítvány

Három különböző objektumot neveznek 'a tanúsítványnak' egy VPN-beállításban. Az ügyfélidentitás egy levéltanúsítvány privát kulccsal, és az átjáró ezzel dönti el, ki Ön. A kiszolgáló saját levéltanúsítványa és a köztes tanúsítványa az, amit ügyfele csatlakozáskor ellenőriz. A bizalmi horgony, általában gyökér- vagy privát CA-tanúsítvány, az, ami a láncot egyáltalán ellenőrizhetővé teszi. RFC 5280 ezeket bizalmi horgonynak, köztes tanúsítványnak és végponti entitásnak nevezi, és a lánc csak addig érvényes, amíg minden láncszem aláírja az alatta lévőt.

Törölje az identitást, és egy eszköz elveszíti a hozzáférést. Törölje a horgonyt, és minden alkalmazás, amely e tároló ellenében ellenőriz, elveszíti a képességét, hogy bármit ellenőrizzen, ami alatta kiadásra került, beleértve azokat a kapcsolatokat is, amelyeknek semmi közük a VPN-hez. Ez az aszimmetria az egész kockázat itt: az egy átjáróhoz telepített gyökér gyakran ugyanaz a gyökér, amely egy belső portált, egy levelezőkiszolgálót vagy egy csomagtükröt aláír. Jegyezze meg, melyik van a kezében.

A tulajdon dönti el, hogy a törlés törölt marad-e. Egy saját laptopon csak Ön teheti vissza a tanúsítványt. Egy felügyelt eszközön egy konfigurációs profil vagy egy MDM-adat hasznos teher a következő bejelentkezéskor újratelepítheti, ezért 'jön vissza', és ezért nem segít a keményebb törlés.

Találja meg, melyik tároló tartja még

Az emberek a Beállítások alkalmazásban kezdik, amely az egyetlen hely, ahol a tanúsítvány nem tárolódik. A valódi helyek az operációs rendszer bizalmi tárolói, a böngésző saját tárolója és az alkalmazás privát tárolója.

A sorozatszám vagy az ujjlenyomat alapján egyeztessen, soha a megjelenített név alapján. A megjelenített neveket az állítja be, aki a tanúsítványt kiadta, és újra felhasználják őket: az 'Example VPN' lehet három tanúsítvány három különböző kulccsal, amelyek közül az egyik még napi használatban van.

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

macOS-en a security eszköz ugyanezeket a tényeket adja, és find-identity megmutatja, mely tanúsítványokhoz van még privát kulcs csatolva:

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

Törölje a szűk objektumot, tartsa meg a közös kibocsátót

Törlés előtt exportáljon. Biztonsági mentés nélkül az egyetlen helyreállítás az újrakibocsátás, ami egy privát CA-nál azt jelenti, hogy vissza kell menni ahhoz, aki a PKI-t üzemelteti. Az exportált PFX az is, amit átad, ha az eltávolításról kiderül, hogy rossz döntés volt.

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

A -user kapcsoló az, amelyet az emberek véletlenül kihagynak. Nélküle a certutil a gép tárolóján dolgozik, ami emelt szintű shellt, más tanúsítványkészletet és olyan hatáskört jelent, amely most a gépen lévő minden más fiókot is lefed.

macOS-en és Linuxon a forma ugyanaz: azonosítsa, exportálja, majd távolítsa el a legszűkebb tárolóból, amely a tünetet magyarázza. A fájl eltávolítása a /usr/local/share/ca-certificates alatt és a update-ca-certificates újrafuttatása elég; --fresh csak akkor segít, ha a /etc/ssl/certs alatti symlinkek már inkonzisztensek. A RHEL család rendszerei a horgonyokat a /etc/pki/ca-trust/source/anchors könyvtárban tartják, ahol trust anchor --remove ugyanazt a munkát végzi.

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

CA-tanúsítvány törlése előtt ellenőrizze, mi mást láncol hozzá. A csomagban lévő alanyok listázása két soros ellenőrzés, és megválaszolja, hogy ez a horgony végez-e más munkát:

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

A fájl törlése nem az identitás visszavonása

Egy helyi törlés egy másolatot távolít el. A privát kulcs még mindig ülhet egy régi jegyhez csatolt p12-ben, egy biztonsági mentési mappában vagy az egyidejűleg beállított második laptopban. Ha ez ügyfélidentitás volt, az átjáró továbbra is elfogadja a kulcs bármely másolatát, amíg az identitást a kiszolgáló oldalán meg nem tagadják.

Egy OpenVPN PKI esetében ez a tanúsítvány visszavonását és annak biztosítását jelenti, hogy a crl-verify által hivatkozott CRL naprakész; easyrsa revoke majd easyrsa gen-crl a rövid változat. Egy identitásszolgáltatóhoz kötött átjáró esetében tiltsa le a felhasználót vagy távolítsa el az eszközt ott, mert a tanúsítvány csak egy hitelesítő adat a játékban. A helyi másolat törlése, miközben a fiók aktív marad, takarításnak látszik, és nem az.

Az incidensmunka más sorrendet követ: először őrizze meg a tanúsítványt, annak sorozatszámát és a visszavonási rekordot, majd töröljön és vonjon vissza. Ezek a rekordok semmibe nem kerülnek, és nem igénylik, hogy működő hitelesítő adatot hagyjon a helyén.

Ellenőrizze kézfogással és egy második alkalmazással

A láncot kívülről ellenőrizze, ne abból a tárolólistából, amelyet épp szerkesztett. A tároló a szerkesztését mutatja; a kézfogás az eredményt.

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

A 0 visszatérési kód azt jelenti, hogy a maradék horgonyok még érvényesítik az átjárót. A horgony eltávolítása utáni lánchiba a várt eredmény, és megerősíti, hogy a használatban lévő horgonyt találta el, nem egy duplikátumot olyan tárolóban, amelyet az ügyfél soha nem olvas. Ha a kapcsolat még működik, keressen második másolatot, az alkalmazásba ágyazott tárolót vagy rögzített tanúsítványt, mindegyik gyakori azoknál az ügyfeleknél, amelyek saját bizalmi listát hoznak.

Aztán teszteljen valami függetlent: egy belső webhelyet, egy levelezőklienst, egy csomagtükröt. Ez olcsón méri a hatáskört, mielőtt a változási ablak bezárul.

• A szerep identitásként, köztes tanúsítványként vagy bizalmi horgonyként azonosítva
• A sorozatszám és az ujjlenyomat rögzítve, a másolat pedig a jóváhagyott helyre exportálva
• A törlés a tünetet magyarázó legszűkebb hatókörben történt
• A kiszolgálóoldali engedélyezés visszavonva, amikor egy személy vagy eszköz távozott
• A kézfogás elmagyarázva, és egy független alkalmazás újra tesztelve
• Az MDM-adat hasznos teher vagy a felügyeleti profil frissítve, különben a tanúsítvány visszatér

Ha a tanúsítvány újraindítás után visszatért, a munka nem fejeződött be: valami birtokolja és újratelepíti. Találja meg ezt a tulajdonost, mielőtt újra töröl, mert a harmadik törlés pontosan úgy viselkedik, mint az első kettő.