Вход в VPN по сертификату на Mac: личность, использование ключа или доверие к шлюзу?
За входом по сертификату стоят три решения: какая личность выбирается, может ли компонент VPN использовать свой ключ и доверяет ли система шлюзу.
Вход в VPN по сертификату просит у Mac нечто более узкое, чем пароль: использовать именно этот закрытый ключ, в этом контексте выполнения, чтобы доказать шлюзу некоторую личность. Когда это не срабатывает, сообщение обычно описывает лишь последнее, что пошло не так, а оно редко бывает причиной. Проход по трём решениям в том порядке, в каком их принимает система, сохраняет диагностику честной и не даёт принять локальную проблему с разрешениями за сбой проверки цепочки.
Пройдите вход в том порядке, в каком это делает Mac
Сначала клиент выбирает личность: сертификат в паре с пригодным закрытым ключом, доступный через поддерживаемое хранилище или поставщика учётных данных. Затем компонент VPN запрашивает криптографическую операцию с этим ключом, и локальная модель авторизации отвечает. Только после успеха обоих происходит удалённое рукопожатие, где Mac оценивает шлюз, а шлюз оценивает доказательство клиента.
| Decision | Typical symptom | Where to look |
|---|---|---|
| Identity selection | No valid identity, wrong certificate offered | Profile and which identity the client picked |
| Local key use | Signing or interaction error before any handshake | Execution context and key access rules |
| Remote authentication | Chain, name or client-admission rejection | Gateway identity and what it accepts |
Читайте таблицу сверху вниз и остановитесь на первой строке, которая не проходит. Всё ниже сбоя не доказано, и поэтому «сертификату не доверяют» — такой частый и такой ненадёжный вывод.
Что на самом деле охватывает локальное разрешение
В модели связки ключей macOS защищённые элементы несут правила доступа, зависящие от операции, и список доверенных программ. Подпись закрытым ключом — одна из таких операций, и правила относятся к исполняемому файлу, который её выполняет, а не к сертификату как документу. Справочник Apple по управлению доступом также проводит границу между этой моделью и связкой ключей iCloud и схемами групп доступа, поэтому совет, написанный для одной, не переносится на другую.
Отсюда следуют два вывода. Видимый в списке открытый сертификат не доказывает, что фоновый компонент VPN вообще может добраться до этого ключа. А разрешение, выданное внешней программе, ничего не говорит об отдельном помощнике или сетевом расширении, потому что это другой код с другими личностями.
Определите фактическую реализацию и поддерживаемый ею механизм совместного использования учётных данных, вместо того чтобы копировать путь к исполняемому файлу из старого клиента. Сначала подтвердите, какую личность система вообще предложит:
security find-identity -v -p ssl-clientКак читать errSecInteractionNotAllowed
Этот статус сообщает о недопустимом взаимодействии с Security Server и ничего не говорит о цепочках сертификатов. Читайте его вместе с операцией, которая его вызвала: запрос подписи, отправленный из контекста, который не может показать приглашение, завершится так же неудачно, даже если и ключ, и сертификат полностью действительны. Начинать нужно с операции, которая это записала, а не с хранилища сертификатов. Любое изменение доверенных якорей оставит ошибку ровно там, где она была.
Поэтому рассматривайте код как повод проверить контекст выполнения и авторизацию. Если считать его доказательством того, что ЦС шлюза не является доверенным, вы попадаете в неверную половину проблемы, и сделанное там изменение вообще не повлияет на ошибку.
Узкая починка, а не широкая
Начните с инструкций по регистрации или импорту от владельца подключения. Зафиксируйте версию клиента, область действия профиля, выбранную личность и первую значимую локальную ошибку, потому что именно эти четыре факта нужны при передаче в поддержку и от них зависит последующее сравнение. Управляемый профиль или личность с аппаратной поддержкой могут потребовать, чтобы администратор или поставщик исправил передачу, и никакое количество локальных щелчков это не заменит.
Там, где продукт ожидает подтверждения пользователя, уточните, какой компонент его запрашивает, и одобрите только этот доступ через поддерживаемый поток. Там, где у компонента нет способа вызвать приглашение в том контексте, в котором он работает, подготовка должна идти по документированному поставщиком пути, а не через диалог, вытащенный из другого окна терминала.
В старых советах две правки объединяют вместе, и обе слишком широки. Предоставление каждой программе доступа к закрытому ключу расширяет локальное использование ключа далеко за пределы требования, а установка сертификата в Always Trust меняет оценку сертификатов для всего на машине. Ни одна из них не выражает «эту одобренную реализацию VPN, использующую эту предполагаемую личность».
Проверьте локально, прежде чем читать шлюз
После починки убедитесь, что локальная операция проходит успешно прежде чем толковать любой ответ с другой стороны. Если подпись теперь работает, последующий отказ по имени, цепочке или допуску клиента — это новый результат, а не повторение, и он относится к другому решению с другим ответственным.
Полезная передача называет, какое из трёх решений не прошло, и на этом останавливается. Она никогда не содержит закрытый ключ и никогда не сбрасывает посторонние элементы связки ключей в надежде, что чистое состояние поможет. Заведите эти две привычки до инцидента, а не во время него, когда искушение попробовать всё сразу сильнее всего. Заявка со словами «связка ключей пересобрана» почти ничего не сообщает следующему читателю о первоначальной неисправности.