Как да премахнете остарял VPN сертификат от хранилище за доверие

VPN клиентът ви е деинсталиран, профилът е изчезнал от Настройки, а тунелът все още се вдига със старите идентификационни данни. Или го изтривате, рестартирате и го намирате отново на следващата сутрин. Нито едно от двете не е счупен бутон за изтриване. Профилът е конфигурация; сертификатът е ключов материал плюс решение за доверие, записано в хранилище, към което профилът само сочи. Кое от двете държите определя какво трябва да означава 'премахване'.

Профилът не е сертификат

Три различни обекта се наричат 'сертификатът' в една VPN настройка. Идентичността на клиента е краен сертификат с частен ключ и шлюзът го използва, за да реши кой сте. Собственият краен сертификат на сървъра и неговият междинен сертификат са това, което вашият клиент проверява при свързване. Котвата за доверие, обикновено коренов или частен CA сертификат, е това, което прави веригата проверима изобщо. RFC 5280 нарича тези котва за доверие, междинен сертификат и краен обект, и веригата се валидира само докато всяка връзка подписва тази под нея.

Изтрийте идентичността и едно устройство губи достъп. Изтрийте котвата и всяко приложение, което валидира срещу това хранилище, губи способността да проверява каквото и да е издадено под нея, включително връзки, които нямат нищо общо с VPN. Тази асиметрия е целият риск тук: корен, инсталиран за един шлюз, често е същият корен, който подписва вътрешен портал, пощенски сървър или огледало за пакети. Запомнете кое от двете държите.

Собствеността решава дали изтриването ще остане изтрито. На лаптоп, който притежавате, вие сте единственият, който може да върне сертификата. На управлявано устройство конфигурационен профил или MDM payload може да го преинсталира при следващата регистрация, ето защо той 'се връща' и защо по-силното изтриване не помага.

Открийте кое хранилище все още го държи

Хората започват от приложението Настройки, което е единственото място, където сертификат не се съхранява. Истинските места са хранилищата за доверие на операционната система, собственото хранилище на браузъра и частното хранилище на приложението.

Съпоставяйте по серийния номер или отпечатъка, никога по показваното име. Показваните имена се задават от този, който е издал сертификата, и се преизползват: 'Example VPN' може да са три сертификата с три различни ключа, един от които все още се използва ежедневно.

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

На macOS инструментът security дава същите факти, а find-identity показва кои сертификати все още имат прикачен частен ключ:

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

Изтрийте тесния обект, запазете споделения издател

Експортирайте преди да изтриете. Без резервно копие единственото възстановяване е преиздаване, което при частен CA означава връщане при този, който управлява PKI. Експортираният PFX е също това, което предавате, ако премахването се окаже грешно решение.

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

Флагът -user е този, който хората пропускат по случайност. Без него certutil работи с машинното хранилище, което означава повишен shell, различен набор сертификати и радиус на въздействие, който вече включва всеки друг акаунт на машината.

На macOS и Linux формата е същата: идентифицирайте, експортирайте, след това премахнете от най-тясното хранилище, което обяснява симптома. Премахването на файла под /usr/local/share/ca-certificates и повторното стартиране на update-ca-certificates е достатъчно; --fresh помага само когато символичните връзки в /etc/ssl/certs вече са несъответстващи. Системите от семейството RHEL пазят котви в /etc/pki/ca-trust/source/anchors, където trust anchor --remove върши същата работа.

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 сертификат, проверете какво друго се верижно към него. Изброяването на субектите в пакета е проверка в два реда и отговаря дали тази котва върши друга работа:

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

Изтриването на файла не е отзоваване на идентичността

Локалното изтриване премахва едно копие. Частният ключ може все още да седи в p12, прикачен към стар тикет, папка за резервни копия или втория лаптоп, настроен по същото време. Ако това беше идентичност на клиент, шлюзът продължава да приема всяко копие на този ключ, докато идентичността не бъде отказана от страна на сървъра.

За OpenVPN PKI това означава отзоваване на сертификата и уверяване, че CRL, посочен от crl-verify , е актуален; easyrsa revoke след това easyrsa gen-crl е кратката версия. За шлюз, свързан с доставчик на идентичност, деактивирайте потребителя или премахнете устройството там, защото сертификатът е само едни от идентификационните данни в игра. Изтриването на локалното копие, докато акаунтът остава активен, изглежда като почистване и не е.

Работата по инциденти има различен ред: първо запазете сертификата, серийния му номер и записа за отзоваване, след това изтрийте и отзовете. Тези записи не струват нищо и не изискват да оставите работещи идентификационни данни на място.

Проверете с ръкостискане и второ приложение

Проверявайте веригата отвън, а не от списъка на хранилището, което току-що редактирахте. Хранилището показва вашата промяна; ръкостискането показва резултата.

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

Код за връщане 0 означава, че останалите котви все още валидират шлюза. Грешка във веригата след премахване на котвата е очакваният резултат и потвърждава, че сте уцелили използваната котва, а не дубликат в хранилище, което клиентът никога не чете. Ако връзката все още работи, потърсете второ копие, хранилище, вградено в приложението, или закрепен сертификат — всички те са чести при клиенти, които доставят собствен списък за доверие.

След това тествайте нещо несвързано: вътрешен сайт, пощенски клиент, огледало за пакети. Това измерва радиуса на въздействие евтино, преди прозорецът за промени да се затвори.

• Ролята е определена като идентичност, междинен сертификат или котва за доверие
• Серийният номер и отпечатъкът са записани, а копието е експортирано на одобреното място
• Изтриването е извършено в най-тесния обхват, който обяснява симптома
• Оторизацията от страна на сървъра е отзована, когато човек или устройство е напуснало
• Ръкостискането е обяснено и едно несвързано приложение е тествано отново
• MDM payload или профил за управление е обновен, иначе сертификатът се връща

Ако сертификатът се върне след рестарт, работата не е свършена: нещо го притежава и го преинсталира. Намерете този собственик, преди да изтривате отново, защото трето изтриване ще се държи точно като първите две.