Comodo AMT SSL Multi-Domain Certificate — купить лицензию Comodo AMT SSL Multi-Domain Certificate по выгодной цене в Анадыре на официальном сайте

Если у вас возникнет серьёзная потребность в написании собственного ПО для АМТ, вы обязательно столкнётесь с обслуживанием сертификатов – в первую очередь это автоматизация их получения. Потому что, как бы это ни было удобно, использовать Manageability Director для такой цели (именно автоматическое получение) – не получится. Intel SCS во многом решает эту задачу, но, повторюсь, если зайдёт речь именно о своём ПО – код SCS, начиная с версии 8.0, закрыт, кроме того, SCS страшно громоздок и негибок, не говоря уже про нелюбовь к линуксу.

Собственно, такая же задача – “автополучение сертификатов” – стоит среди главных для того же MDM и любой другой сферы, связанной с шифрованием посредством “привычных” сертификатов. Если по-простому, то для какого-то устройства, которое нуждается в сертификате, должна быть возможность отправить запрос по http/https  и получить в ответ сертификат, выписанный от имени нашего CA.

Такую задачу решает SCEP (Simple Certificate Enrollment Protocol) сервер. В версии от микрософт (MSCEP) она реализуется с помощью NDES (Network Device Enrollment Service) сервиса. Далее опишу настройку SCEP для выдачи AMT-сертификатов. (При чём не только для TLS-шифрования, но и для инициализации/управления, что пригодится нам после, при рассмотрении работы AMT7 , поддерживающих HostBasedSetup, где как раз такие и требуются).

Как обычно, при настройке MS-сервисов, я не акцентирую внимание на подробностях их работы – это другая тема. Считаю правильным сделать “пошаговую инструкцию”, чтобы по картинкам любой мог это же повторить, и останавливаюсь подробней лишь на важных и проблемных моментах.

В “полной” версии MSCEP предполагает наличие отдельного сервера с домен-контроллером, отдельного для СА и отдельного для SCEP (NDES) – итого 3 шт.

Однако я исхожу из предположения, что ПО предполагает условно “малый бизнес” (Small Business), где количество/стоимость обслуживания виртуалок для этого играет значение, потому опишу настройку всего этого на одной виртуалке.

То есть с DC СА SCEP в одном флаконе.

В моём случае она поднимается на Amazon EC2, достаточно варианта с 1.7Гб памяти (по опыту нужно от 1Гб, использовать самые “бюджетные” виртуалки с 640Мб крайне не рекомендуется – глюки с получением сертификатов крайне многовероятны).

Поставив домен и СА (см. руководство из прошлой части) приступаем к установке NDES (т.е. собственно, SCEP-сервера).

Сначала создадим юзеров (в домене):

• админа SCEP
• юзера из-под которого будет запускаться сервис SCEP (NDES)
• Device-админа, который будет иметь права на получение сертификата “со стороны устройства” (по простому – через веб-интерфейс)

Я обзываю их SCEPadmin, SCEPservice и DeviceAdmin.

SCEPadmin добавляем в группу “Administrators”, SCEPservice в группу “IIS_IUSRS”.

Далее добавляем ещё одну роль для CA:

Ставим галку напротив NDES:

На следующем шаге прописываем нашего пользователя с правами “IIS_IUSRS”, из-под которого будет трудиться NDES.

Наличие группы “IIS_IUSRS” у данного юзера (SCEPservice ) принципиально, иначе получите ошибку 0x80070529:

Тут заполняем, что хотим (не принципиально):

На следующей можно ничего не трогать.

Проверяем и запускаем установку:

После окончания установки, если у вас до этого уже была открыта консоль с шаблонами – её нужно обновить, чтобы отобразились свежедобавленные в результате шаблоны. Для нас важен будет, появившийся после установки NDES – шаблон “CEP Encryption“.

Добавляем SCEP-админа (SCEPadmin) для “CEP Encryption“:

И даём ему права на “Enroll“:

Далее аналогично для шаблона “Exchange Enrollment Agent (Offline request)” – добавляем “Enroll” для SCEPadmin:

Далее настраиваем админу SCEP права на добавление шаблонов в СА:

Ставлю все галки в закладке “Security“:

И, наконец, добавляем SCEP-админа в “Administrators” и “Enterprise Admins”:

Настраиваем пользователя, из-под которого запускается NDES, в моём случае это SCEPservice. Ранее мы его уже добавили в группу “IIS_IUSRS”. Однако подразумевается именно локальная группа, потому, из-за того, что мы делаем это “прямо на домене” (где “всё в одном” – DC CA SCEP), придётся добавить SCEPservice в группу “Administrators”.

Иначе (если  не добавить SCEPservice в администраторы) после SCEP-ApplicationPool просто не стартанёт (будем получать ошибку 503 – “Service Unavailable“), т.к. у данного пользователя не будет прав на вход в систему.

The identity of application pool SCEP is invalid. The user name or password that is specified for the identity may be incorrect, or the user may not have batch logon rights.

Далее, ещё SCEPservice нужны права на запрос сертификатов из СА:

Кроме этого ему требуются “Read” и “Enroll” для шаблона, с помощью которого мы будем отдавать сертификаты. По умолчанию, после установки NDES, это шаблон “IPSec (Offline request)“. Поэтому мы настроим всё нужное для него, а после сделаем на базе оного шаблон для Intel AMT.

Итак, для шаблона “IPSec (Offline request)” ставим SCEPservice права на “Read” и “Enroll“:

Наконец, добавляем SPN для SCEPservice. Для этого выполняем в командной строке:

setspn -a SCEPservice/scs.my-sertif.ruscs
(в вашем случае имя сервиса и домен прописываем своё)

Для DeviceAdmin-а, аналогично SCEPservice, добавляем права на “Enroll” для “IPSec (Offline request)“:

Настройка аккаунтов закончена, теперь на базе “IPSec (Offline request)” сделаем шаблон для Intel AMT.

Шаблон SCEP для Intel AMT

Делаем дубликат “IPSec (Offline request)“:

Выбираем 2003:

Я обзываю его “AMTinitTLS” – он будет и для инициализации (пригодится для AMT7 ) и для TLS.

В названии посоветую не использовать пробелов/подчёркиваний, чтобы после не спутать имя и отображаемое имя шаблона.

Я минимальный размер ключа с дефолтных 2048 понижаю до 1024 (AMT поддерживает 1024–2048):

Добавляем галку “Microsoft Strong Cryptographic Provider“:

Проверяем/ставим “Supply in the request” в “Subject Name“:

Проверяем/ставим “Read” и “Enroll” для SCEPservice в закладке “Security“:

Добавляем в “Extensions” политики “Client Authentication” и “Server Authentication“:

Вышеописанные шаги для шаблона AMT мы уже делали при настройке TLS-сертификатов для Intel SCS. “Client Authentication” и “Server Authentication” – это “обычные” политики для SSL-сертификатов. Сейчас же добавим ещё и “необычных”, специфичных именно для Intel AMT.

Настройка OID, специфичных для Intel AMT

На “Add Application Policy” жмём “New” и в поле OID вводим 2.16.840.1.113741.1.2.3 (предварительно очистив это поле от того, что там по умолчанию). Это политика, необходимая для инициализации AMT, потому обзываю её, например, “AMT init”:

Аналогично повторяем и вводим 2.16.840.1.113741.1.2.1 – требуемая политика для удалённого доступа, называю “AMT remote access”:

И для локального доступа 2.16.840.1.113741.1.2.2 – “AMT local access”:

В результате получим следующий набор политик:

Для “красоты” можно удалить политику IPSec – останутся все те, что требуются для работы Intel AMT.

Применяем все изменения и получаем новый шаблон.

Добавляем “AMTinitTLS” в шаблоны СА:

Рестартим СА для публикации новодобавленного шаблона:

Шаблоны на месте, приступаем к следующей стадии.

Существует много всяких разных способов защиты от того, чтобы враги не получали наши сертификаты. Для этого много разных навороченных механизмов может быть реализовано, например, предоставление устройством истекающего сертификата в качестве “пароля”, взамен ему выдаётся новый. Подобные схемы крайне сложны, для нашего случая (напомню, подразумевается условный Small Business) – настроим простую-понятную схему “с паролем”.

Однако и тут сложности – по дефолту пароль (который проверяется при запросе сертификата) одноразовый, т.е. он меняется после выписывания каждого сертификата. Такие сложности ни к чему, переделаем на постоянный пароль. Для этого придётся лезть в реестр.

Ищем ветку “HKEY_LOCAL_MACHINESoftwareMicrosoftCryptographyMSCEP“:

Меняем на единичку:

Видим, что в реестре стоит дефолтный шаблон – “IPSECIntermediateOffline“:

Однако мы добавили в СА и хотим выдавать свой, а не дефолтный, потому меняю его (все три поля) на “AMTinitTLS” (имя шаблона, выше нами сделанного):

Далее нужно добавить возможность изменять данную ветку реестра пользователю, из-под которого стартует NDES (у меня это SCEPservice).

Для этого даём ему Full Control:

Ну и последний штрих – настраиваем IIS. Для этого в свойствах “Application Pool” – “SCEP” жмём “Advanced Settings“:

Меняем “Load User Profile” с дефолтного “False” на “True“:

Перезагружаем IIS командой iisreset и заходим по адресу http://192.168.0.197/CertSrv/mscep_admin/ (тут, конечно, у каждого свой адрес/IP) и вводим логин-пароль DeviceAdmin-а:

Наконец, получаем долгожданный результат:

Мы получили сгенерированный постоянный пароль (Enrollment Challenge Password), которым можно пользоваться для автоматического получения сертификатов с помощью HTTP и HTTPS (настроим в следующей части) запросов.

В общем, SCEP-сервер настроен и готов к работе.