Настройка TLS-сертификатов с помощью Manageability Commander

Статья "Настройка TLS-сертификатов с помощью Manageability Commander" из серии "Учебник по Intel AMT", часть десятая.

См. также:

Сертификаты в АМТ используются не только (и даже не столько) для инициализации, сколько для обеспечения шифрованного канала управления проинициализированным АМТ-компьютером. Все предыдущие рассмотренные нами примеры давали на выходе возможность управлять АМТ-компьютером лишь по незащищённому каналу. В таком случае мы присоединяемся к нему на порт 16992. Шифрованный же канал - это порт 16993, на который в частности, и отправляются данные в момент инициализации (т.к. начиная с АМТ 2.0 она проходит по шифрованному каналу).
Получив после инициализации возможность "работать с АМТ", защитим теперь канал связи с помощью TLS-сертификата. Познакомившись уже, как такое работает в Директоре, разовьём данную тему в Командере.

Manageability Commander (MDTK)

Manageability Commander из пакета MDTK - одна из самых популярных утилит для работы с АМТ (даже, скорей - самая популярная). Имеет большой набор возможностей, является логичным продолжением Директора, который "заточен" на инициализацию, в то время как Командер - на конфигурирование.

Manageability Commander 6.0.10314.2

Последний из доступных Командеров, который работал корректно для старых версий. Начиная с версии 7 и до текущих (на момент написания статьи это OpenMDTK v0.1.31) - корректно с ними уже не работают. Точней работают, но не во всём - нужное нам в этой статье добавление сертификатов вылетает в различные ошибки. Однако их можно обойти - тоже рассмотрим как. Однако для начала, всё же, возьмём версию Командера 6.0:

Manageability Commander 6.0.10314.2

Присоединяемся к ранее проинициализированному компьютеру. Переходим на закладку Intel Management Engine и видим список основных настроек.

Пройдёмся по каждой отдельно.

Computer Hostname / Domain

Имя компьютера и домен. Чтобы не было проблем - необходимо использовать и имя, и домен, т.е конечное название типа amt4.vpro.by (рекомендуется) или mycomputer.local.domain (не рекомендуется). Имя - 31 символ, домен 32 символа максимум (условно ещё один символ до 64-х съедает точка).

Это не максимально возможные значения - можно сделать и длиннее (завист от версии, с АМТ 6 и новей - можно больше). Однако в реальности, на практике - ошибки при больших значениях многовероятны, да и смысла особого делать длинней как правило нет.

Первая точка слева отделяет домен от имени, т.е. в программах, где указано лишь одно поле для "hostname/domain" при указании "amt4.vpro.by" на деле в имя пропишется "amt4", а в домен "vpro.by".

По дефолту Командер даёт компьютеру "прошитое" (в настройках не меняется - нужно править исходники, если вам это критично) имя "Setup-PKI.dtk.amt.intel.com". Чуть позже мы его обязательно изменим, пока оставим без изменения.

Intel AMT Version

Версия АМТ, в нашем случае 4.2.60.1060 - последняя из AMT 4.х.

BIOS Version

Версия биоса - здесь также последняя (лето 2012-го года) версия.

Intel ME Power

Режим работы ME в различных состояних  компьютера (описываем Sx). Изначально для ноутбуков это "ON in S0", который мы уже раньше меняли в MEBx. Здесь проделаем аналогично, но уже удалённо, т.е. без захода в MEBx. Жмём звёздочку и ставим нужное (во всех режимах при подключении к электросети и только во включенном состоянии от батареи):

Power Saving Management

User Accounts

Данный раздел аналогичен тому, что мы рассматривали в Директоре в Access Control Setup (тут можно добавить-изменить, сделанное им в профиле). Смысла изменять нет, потому ничего и не меняем.

Interaction Type

Доступные протоколы для работы с Intel ME. Начиная с АМТ3 протокол SOAP "начали хоронить", правда окончательно похоронили лишь в АМТ9. Здесь для особых ценителей можно вручную ускорить этот процесс - запретить использование SOAP, оставив лишь "прогрессивный" WSMAN.

WSMAN Settings

В общем, толку тут нет, не меняем.

Certificate & CRL Store

Хранилище сертификатов - то, что нам и нужно. Жмём звёздочку:

Certificate Store

Видим пустые закладки. Это значит, что в нашем хранилище ничего нет. А для того, чтобы работало шифрование - должно быть. Жмём New… Если у вас вылетела ошибка - читайте дальше (как обойти), в описываемых (старых) Коммандерах всё должно работать:

Certificate Store New Certificate

Появляется диалог создания сертификата, по умолчанию в качестве "издателя" ("Issuer") прописывается тот, что мы создавали раньше (наш собственный root-сертификат). В выпадающем списке их может быть два с одинаковым именем - из-за того, что он находится и в "личных" и в "трастовых" (это уже про хранилище сертификатов Windows - разберёмся позже отдельно). В общем, ориентируемся по имени. Также можно прямо здесь создать новый рут. Но это ещё более проблемная (для Коммандера) опция - с большой долей вероятна ошибка, потому лучше пользоваться ранее созданным в Директоре. Или прямо по ходу, "параллельно", зайти в него, сделать нужные сертификаты, переключиться в Командер и нажать File - Certificate Manager - Refresh Displayed Certificates:

Certificate Manager Refresh

Итак, выбираем наш рут. Далее очень важный момент - имя, на которое выписываем сертификат. Оно должно в точности совпадать с тем, что имеет АМТ-компьютер (см. первый пункт "Computer Hostname / Domain"). Однако это ещё не всё. Также оно должно корректно "разрешаться" (DNS-сервером) в вашей сети, это значит, что набрав в командной строке ping + имя АМТ-компьютер , вы получите попытку пингования айпишника конфигурируемого АМТ-компьютера.

Я для реализации этого стандартно пользуюсь DNS-админкой Яндекса, где "живёт" у меня домен vpro.by. Просто создаю очередной поддомен, указав ему айпишник АМТ-компьютера внутри локальной сети.

sub domain amt4

Теперь при "ping amt4.vpro.by" получаю:

Обмен пакетами с amt4.vpro.by [192.168.0.143] с 32 байтами данных:

Сам пинг может не проходить (если он запрещён в Windows), тут главное то, что имя "amt4.vpro.by" корректно переводится (или по-умному "разрешается" - DNS-сервером, в данном случае Яндекса) в айпишник AMT-компьютера. А для того, чтобы IP не менялся при используемом по дефолту DHCP, я его (в данном случае MAC-адрес проводного интерфейса и нужный IP) прописываю его в статические.

Static DHCP

Для чего всякие такие подробности - увидим дальше. Каждый волен реализовывать такое соответствие по-своему, я лишь демонстрирую привычное мне.

Итак, возвращемся к нашему имени сертификата. В описанном только что моём случае с ноутбуком Lenovo T400, который у меня в подсети имеет IP 192.168.0.143 (точней - его Ethernet-интерфейс) - я прописываю имя сертификата "amt4.vpro.by".

Certificate Store New Certificate amt4.vpro.by

Другие поля аналогично ранее описанным, можно заполнять от балды, в том числе размер ключа (в АМТ поддерживаются 1024-2048).

Получаем картинку:

Certificate Store 1 cert

1 сертификат в хранилище. Можно добавить ещё три - всего 4 максимум.

Далее, "чтобы два раза не вставать", можно зайти во вторую закладку (Trusted Roots) и добавить в трастовые наш рут-сертификат.

Certificate Store Trusted Roots

Сейчас нам это не пригодится - с этим придётся столкнуться, когда будем разбираться с двунаправленной (клиент-серверной) авторизацией. В общем, в выпадающем списке (в котором "светятся" все, что находятся в виндовом хранилище сертификатов раздела "доверенные центры сертфикации" - куда мы добавили и свой рут) выделяем наш рут и жмём Add:

Certificate Store Trusted Roots AMT-guide

Последняя закладка "отозванных сертификатов" (Revocation) нам не пригодится - сюда можно удалённо добавлять список сертификатов, которые мы "отозвали", т.е. они "перестали быть валидными" (хотя с точки зрения подписи-сроков и т.п. вполне "нормальные"). Простейший пример - враги украли какой-то - можно добавить сюда, чтобы они по нему "не просочились".

Закрываем, теперь картинка чуть изменилась:

Certificate and CRL Store

Это мы добавили один сертификат для TLS-шифрования ("amt4.vpro.by") и один трастовый рут ("AMT-guide").

Kerberos Setup

Настройки для интеграции с виндовой (Active Directory) аутентификацией. Нам это не пригодится, пропускаем.

Remote Access

Настройки CIRA, пока пропускаем, после это станет важной частью описания возможностей АМТ4+ версий.

Тут лишь могу отметить, только заметил — данная версия Командера ошибается и пишет, что данный функционал Unsupported (хотя реально - поддерживается). Ладно, сейчас нам не критично, а это лишнее отражение того, почему я стараюсь описывать разные версии MDTK - в старых есть ошибки, но в новых, где они исправлены - добавлены другие ошибки и пропадает корректная поддержка старых версий АМТ…

Alarm Clock Settings

Настройки "будильника", появившегося а в АМТ5. Потому здесь уже справедливо Unsupported.

Transport Layer Settings (TLS)

Главный пункт данной статьи - настройка TLS-шифрования. Жмём звёздочку:

Edit TLS Settings

Видим, что сейчас TLS-шифрование не включено. Ставим галку:

Edit TLS Settings Select TLS

В выпадающем списке, если всё до этого сделали правильно — добавили ранее в пункте "Certificate & CRL Store" наш сертификат (-ы)  — тут можно будет что-то выбрать. В моём случае это "amt4.vpro.by / AMT-guide" (сертификат / от кого выдан). Жмём ОК, после в дополнительных TLS-опциях ничего не ставим и снова ОК.

Edit TLS Settings OK

В этот момент соединение с АМТ-компьютером разрывается. Кликаем по значку компьютера, чтобы пересоединиться.
Спустя "непривычно длительное" (возможно очень длительное - зависит от версии Командера) время (по сравнению с вариантом без шифрования) - появится красный значок АМТ-компьютера:

cert mismatch

В нижнем окошке указаны причины - что "не понравилось" Командеру (т.е. почему значок красный). Они как раз связаны с тем, что для корректной работы TLS-соединения с АМТ-компьютером, как и писалось выше, должны совпадать три вещи:

  1. Имя компьютера (точней "имя.домен").
  2. Имя на которое выдан сертификат.
  3. DNS-имя, по которому мы присоединяемся к компьютеру.

Итак, дожидаемся, пока загорятся все звёздочки настроек (это в зависимости от состояния АМТ компьютера может занять минуту-другую) и вкладке Intel Management Engine жмём уже описанную выше "Computer Hostname / Domain".

Computer Name Domain

Не зря звёздочка горит красным - видно, что все поля в блоке "Intel AMT Host Name" отличаются. А должны быть одинаковые. Исправляем. Меняем "командерно-дефолтно-интеловское" на amt4.vpro.by (у вас, понятно, будет свой вариант).

Computer Name Domain changed

Теперь первые два пункта совпадают. Однако третий (DNS-имя) - нет. Это не решается настройками, это решается тем, как раз для чего я создавал поддомен с amt4.vpro.by. Нужно пересоединиться не на айпишник (на который по дефолту коннектятся утилиты MDTK), а на имя, в моём случае amt4.vpro.by.

Жмём Network, правая клавиша мыши, Add Intel AMT Computer:

Network Add AMT-computer

Добавляем DNS-имя АМТ-компьютера:

Add AMT-computer

Жмём и ОК и дважды кликаем по свежесозданной иконке АМТ-компьютера:

connect through dns name

Готово! Синяя иконка говорит о том, что никаких ошибок.

Красная иконка "предыдущего" соединения (через IP-шник) осталась и даже продолжает работать (т.к. АМТ поддерживает "мультисессионность"). Однако смысла в ней уже нет - закрываем и наслаждаемся защищённым соединением (правда "красное" тоже уже было защищённым - однако некоторые критичные к этим ошибкам фичи по управлению через АМТ так бы не работали).

Зайдём посмотрим-убедимся:

Computer Name Domain 4eq

Что и требовалось.

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступные HTML теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.
Anti-bot.