На этой странице
Как правило, инфраструктура сертификата настраивается на использование одного корневого ЦС в трехуровневой иерархии, состоящей из корневого ЦС, промежуточных ЦС и выдающих ЦС. При использовании VPN-подключений выдающие ЦС настроены для выдачи сертификатов компьютеров или сертификатов пользователей. Вместе с сертификатом пользователя или компьютера на VPN-клиент одновременно устанавливаются сертификаты выдающего ЦС, промежуточного ЦС и корневого ЦС. Вместе с сертификатом компьютера на сервер проверки подлинности одновременно устанавливаются сертификаты выдающего ЦС, промежуточного ЦС и корневого ЦС. ЦС, выдающий сертификат компьютера для сервера проверки подлинности, может отличаться от ЦС, выдающего сертификаты для VPN-клиентов. В этом случае VPN-клиент и компьютер сервера проверки подлинности должны иметь все необходимые сертификаты для проверки сертификатов при помощи IPSec и EAP-TLS. При развертывании инфраструктуры сертификата учитывайте следующие рекомендации:
| • | Спланируйте инфраструктуру сертификата до начала развертывания центров сертификации. |
| • | Корневой ЦС должен быть автономным и подписанным ключом, защищенным при помощи аппаратного модуля безопасности HSM (Hardware Security Module, HSM). Ключ должен храниться в надежном месте для того, чтобы свести к минимуму возможность компрометации ключа. |
| • | Организации не должны выдавать сертификаты пользователям или компьютерам непосредственно при помощи корневого ЦС. Вместо этого рекомендуется развернуть: 1. Автономный корневой ЦС.
2. Автономные промежуточные ЦС.
3. Автономные выдающие ЦС.
Данная инфраструктура ЦС обеспечивает гибкость и изолирует корневой и промежуточные ЦС от попыток скомпрометировать их закрытые ключи злоумышленниками. Автономные корневые и промежуточные ЦС не обязательно должны являться ЦС Windows 2000. Выдающие ЦС могут подчиняться промежуточным ЦС сторонних производителей. |
| • | Выполняйте архивирование базы данных ЦС, сертификатов и ключей ЦС, чтобы предотвратить потерю критических данных. Архивирование ЦС должно производиться регулярно (ежедневно, еженедельно, ежемесячно) в зависимости от количества сертификатов, выдаваемых за определенный период времени. Чем больше выдается сертификатов, тем чаще должно производиться архивирование ЦС. |
| • | Вы должны пересмотреть принципы разрешений безопасности и контроля доступа, так как центры сертификации предприятия выдают сертификаты, основанные на разрешениях безопасности для запроса сертификатов. |
Если Вы хотите воспользоваться преимуществами автоматической подачи заявок на сертификаты компьютера и заявок на сертификаты при помощи оснастки Сертификаты (Certificates), используйте службы сертификации (Certificate Services) Windows 2000 и создайте выдающий ЦС предприятия.
Для получения дополнительной информации обратитесь к разделам Контрольный список: внедрение центров сертификации и инфраструктуры открытого ключа для интрасети (Checklist: Deploying certification authorities and PKI for an intranet) и Контрольный список: Создание иерархии сертификации с автономным корневым центром сертификации (Checklist: Creating a certification hierarchy with an offline root certification authority) справки Windows 2000 Server.
Отзыв сертификата и проверка подлинности ЕAP-TLS
По умолчанию во время процесса проверки подлинности EAP-TLS сервер проверки подлинности проверяет все сертификаты (на предмет того, не отозваны ли они) в цепочке, отправленной VPN-клиентом. Если отзыв сертификата завершается неудачно для любого из сертификатов в цепочке, подключение не проходит проверку подлинности и отклоняется. Проверка отзыва сертификата может завершиться неудачно по следующим причинам:
| • | Сертификат был отозван. Поставщик сертификата отозвал данный сертификат. |
| • | Список отзыва сертификатов (certificate revocation list, CRL) для данного сертификата недоступен или недействителен. Центры сертификации содержат CLR и публикуют их в заданных точках распространения списков CLR. Точки распространения списков CLR включены в свойство Точки распространения списков отзыва (CRL) сертификата. Если точки распространения списков CRL не доступны для проверки отзыва сертификата, проверка завершится неудачей. К тому же, если сертификат не содержит информации о точках распространения списков CRL, сервер проверки подлинности не сможет проверить, был ли отозван сертификат, и проверка отзыва сертификата завершится неудачей. |
| • | Имя поставщика списка CRL не соответствует имени поставщика сертификата. Список CLR содержит информацию о выпустившем его ЦС. Если ЦС, опубликовавший список CLR, не совпадает с ЦС, выдавшим сертификат, для которого осуществляется проверка отзыва, проверка завершится неудачей. |
| • | Неверная дата списка CRL. Все выпущенные списки CRL имеют диапазон действительных дат. Если дата следующего обновления списка CLR истекла, список CLR признается недействительным и проверка отзыва сертификата завершится неудачей. Новые списки CLR должны быть опубликованы до истечения срока последнего опубликованного списка CLR. |
Данное свойство можно изменить при помощи настроек реестра в разделе
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP\EAP\13
на сервере проверки подлинности:
| • | IgnoreNoRevocationCheck. Если задано значение 1, сервер проверки подлинности разрешает подключения EAP-TLS-клиентов даже в том случае, если не удается выполнить или завершить проверку отзыва цепочки сертификатов от клиента (за исключением корневого сертификата). Как правило, проверка отзыва сертификата завершается неудачей из-за того, что сертификат не содержит информации о списках CRL. Значение параметра IgnoreNoRevocationCheck по умолчанию равно 0 (выключено). EAP-TLS-клиенты не смогут подключаться до тех пор, пока сервер проверки подлинности не завершит проверку отзыва для цепочки сертификатов от клиента (включая корневой сертификат) и не проверит то, что ни один из сертификатов не был отозван. Вы можете использовать данное значение параметра для проверки подлинности клиентов в тех случаях, когда сертификат не содержит информации о точках распространения списков CRL, (в случае, когда он получает их от сторонних издателей). |
| • | IgnoreRevocationOffline. Если задано значение 1, сервер проверки подлинности разрешает подключения EAP-TLS-клиентов даже в том случае, если сервер, хранящий списки отозванных сертификатов, не доступен в сети. Значение параметра IgnoreRevocationOffline по умолчанию равно 0. EAP-TLS-клиенты не смогут подключаться до тех пор, пока сервер проверки подлинности не завершит проверку отзыва для цепочки сертификатов от клиента и не проверит то, что ни один из сертификатов не был отозван. В том случае, если невозможно соединиться с сервером, хранящим списки отзыва, EAP-TLS-клиенты с соответствующими сертификатами не смогут пройти проверку отзыва. Установите значение параметра равным 1, чтобы предотвратить ошибку проверки сертификата из-за некачественного сетевого соединения, препятствующего успешному завершению проверки отзыва этих сертификатов. |
| • | NoRevocationCheck. Если задано значение 1, сервер проверки подлинности отменяет проверку отзыва EAP-TLS для сертификатов беспроводных клиентов. Проверка отзыва сертификатов удостоверяет то, что сертификаты VPN-клиентов и сертификаты в их цепочках сертификатов не были отозваны. Значение параметра NoRevocationCheck по умолчанию равно 0. |
| • | NoRootRevocationCheck. Если задано значение 1, сервер проверки подлинности отменяет проверку отзыва EAP-TLS для корневого сертификата VPN-клиентов. Значение параметра NoRootRevocationCheck по умолчанию равно 0. Данное значение параметра отменяет только проверку отзыва для сертификата корневого ЦС данного клиента. Для цепочки сертификатов данного VPN-клиента проверка отзыва продолжает выполняться. Вы можете использовать данное значение проверки подлинности клиентов в том случае, если сертификаты этих клиентов не содержат информации о точках распространения списков CRL (в случае, когда он получает их от сторонних издателей). Также данное значение параметра может предотвратить задержки, связанные с сертификацией, возникающие в том случае, когда список отзыва сертификатов не доступен в сети, или срок его действия истек. |
Все вышеперечисленные значения реестра должны быть добавлены в виде параметра DWORD и могут иметь значения 0 или 1. VPN-клиент не выполняет проверку отзыва сертификата сервера проверки подлинности и не использует данные значения.
Поскольку проверка отзыва сертификата может препятствовать доступу через VPN из-за недействительности или недоступности списков CRL для всех сертификатов в цепочке, проектируйте Вашу инфраструктуру сертификата с учетом высоких требований к доступности списков CRL. Для этого настройте множественные точки распространения списков CLR для каждого ЦС в иерархии сертификатов и настройте публикацию по расписанию, чтобы обеспечить постоянный выпуск и доступность текущих списков CRL.
Проверка отзыва сертификатов будет корректной только при наличии последних опубликованных списков CRL. Например, если сертификат отозван, по умолчанию новый список CRL, содержащий сертификаты, отозванные позже, не публикуется автоматически. Как правило, списки CRL публикуются на основе настраиваемого планировщика. Это означает то, что отозванные сертификаты могут продолжать использоваться для проверки подлинности, так как опубликованный список CRL не является текущим; он не содержит отозванных сертификатов и, тем не менее, может продолжать использоваться для создания беспроводных подключений. Чтобы предотвратить это, сетевой администратор должен вручную опубликовать новый список CRL с недавно отозванными сертификатами.
По умолчанию сервер проверки подлинности использует информацию о точках распространения списков CRL, содержащуюся в сертификатах. Также имеется возможность хранить локальную копию списка CRL на сервере проверки подлинности. В этом случае во время проверки отзыва сертификата используется локальный список CRL. Если в Active Directory вручную опубликован новый список CRL, локальный список CRL на сервере проверке подлинности не будет обновлен. Локальный список CRL обновляется по истечении срока действия. Это может привести к ситуации, при которой сертификат отозван, список CRL опубликован вручную, но сервер проверки подлинности продолжает разрешать подключения из-за того, что локальный список CRL еще не обновлен.
Наверх страницы
Использование сторонних ЦС для проверки подлинности EAP-TLS
Вы можете использовать центры сертификации сторонних производителей для проверки подлинности EAP-TLS до тех пор, пока установленные сертификаты могут быть проверены и имеют соответствующие свойства.
Сертификаты серверов проверки подлинности
Сертификат компьютера сервера проверки подлинности (VPN-сервера или IAS-сервера) должен соответствовать следующим условиям:
| • | Сертификаты должны быть установлены в локальное хранилище компьютера для сертификата. |
| • | Сертификаты должны иметь соответствующий закрытый ключ. |
| • | Поставщик службы криптографии сертификатов должен поддерживать безопасный канал SChannel. В противном случае сертификат будет нельзя использовать. Его также нельзя будет указать в качестве значения параметра Смарт-карта или иной сертификат (Smart Card or Other Certificate) на вкладке Проверка подлинности (Authentication) в настройках профиля политики удаленного доступа. |
| • | Сертификат должен содержать цель (также известную как Enhanced Key Usage, EKU – использование расширенного ключа) «Проверка подлинности сервера». EKU определяется при помощи идентификатора объекта (object identifier, OID). OID для цели «Проверка подлинности сервера» имеет значение «1.3.6.1.5.5.7.3.1». |
| • | Сертификат должен содержать полное доменное имя (fully qualified domain name, FQDN) учетной записи компьютера сервера проверки подлинности, указанное в поле сертификата Дополнительное имя владельца (Subject Alternative Name). |
Дополнительно сертификаты корневого ЦС для центров сертификации, выдающих сертификаты пользователя для VPN-клиентов, должны быть установлены в хранилище сертификатов доверенного корневого центра сертификации на серверах проверки подлинности.
Сертификаты компьютеров VPN-клиентов
Сертификаты, установленные на компьютеры VPN-клиентов, должны соответствовать следующим условиям:
| • | Сертификаты должны иметь соответствующий закрытый ключ. |
| • | Сертификаты должны содержать значение EKU «Проверка подлинности клиента» (OID –«1.3.6.1.5.5.7.3.2»). |
| • | Сертификаты должны быть установлены в хранилище сертификатов текущего пользователя. |
| • | Сертификаты должны содержать универсальное основное имя (Universal Principal Name, UPN) учетной записи пользователя, указанное в поле сертификата Дополнительное имя владельца (Subject Alternative Name). |
Кроме того, сертификаты корневого ЦС для центров сертификации, выдающих сертификаты компьютера IAS-серверу, должны быть установлены в хранилище сертификатов доверенного корневого центра сертификации на компьютерах VPN-клиентов.
