О чём ролик
Разбираем два маршрута установки Clearway CA: все основные компоненты на одной машине и корневой и выдающий центры сертификации на отдельных серверах. Показываем порядок просмотра курса, место дополнительных сервисов и работу с результатами и историей развёртывания.
Длительность
03:38
| Время | Действие |
|---|---|
| 00:00 | Два варианта установки. Выбрать маршрут в зависимости от размещения компонентов. |
| 00:14 | Быстрая установка на одной машине. Понять, какой результат даёт общий сервер с корневым ЦС, OpenID и Контрольной панелью. |
| 00:28 | Состав быстрого сценария. Разобраться, какие дополнительные сервисы устанавливаются вместе с ЦС; MS-WSTEP рассматривается отдельно. |
| 00:48 | Корневой и выдающий центры. Разделить подпись сертификата выдающего ЦС и выпуск сертификатов конечным владельцам. |
| 01:07 | Подключение управления и сервисов. Определить место OpenID, Контрольной панели, публикации, OCSP и других компонентов. |
| 01:28 | Порядок просмотра. После подготовки перейти к главе 2 для одной машины либо к главам 3–11 для распределённой схемы. |
| 01:45 | Как устроена работа в курсе. Связать задачу, действия в веб-мастере и проверку результата. |
| 02:03 | Файлы результата установки. Сохранять загруженные браузером сертификаты, запросы и другие результаты для следующих шагов. |
| 02:28 | История развёртываний. Найти ранее выполненные операции, их параметры, статусы и результаты. |
| 02:57 | Подробности операции и терминальный вывод. Использовать результаты отдельных шагов и журналы для разбора проблем. |
| 03:17 | Границы курса и следующий шаг. Отделить новую установку и первую резервную копию от отдельных тем обновления, миграции и аварийного восстановления. |
О чём ролик
Готовим рабочее место оператора и целевые серверы для установки Clearway CA. Проверяем ОС, имена и синхронизацию времени, разбираем ресурсы и сетевые соединения, устанавливаем пакет инсталлятора и открываем веб-мастер.
Длительность
06:14
| Время | Действие |
|---|---|
| 00:00 | Что подготовить перед установкой. Получить рабочий веб-мастер и готовые к подключению серверы. |
| 00:20 | Рабочее место и целевые серверы. Разделить Linux-машину с браузером и узлы, к которым мастер подключается по SSH. |
| 00:39 | Проверка операционной системы. Уточнить дистрибутив и версию перед установкой пакета. |
| 00:54 | Ресурсы одной машины. Сопоставить конфигурацию общего сервера с предполагаемой нагрузкой. |
| 01:18 | Ресурсы при раздельном размещении. Запланировать CPU, память и диск для ЦС, OpenID и вспомогательных сервисов. |
| 01:45 | Имена серверов и время. Проверить полное имя, разрешение сервисного имени и синхронизацию часов. |
| 02:34 | Направления соединений. Согласовать доступ по SSH, к мастеру, веб-сервисам, API ЦС, PostgreSQL и OCSP. |
| 03:33 | Установка пакета инсталлятора. Найти полученный DEB-пакет и установить приложение. |
| 04:10 | Проверка установки и запуск. Убедиться, что пакет зарегистрирован, команда доступна и приложение запущено. |
| 04:48 | Открытие мастера в браузере. Перейти к локальному HTTPS-адресу и проверить сертификат интерфейса. |
| 05:40 | Быстрый и расширенный режимы. Найти нужный вариант развёртывания. |
| 05:53 | Итоговая проверка подготовки. Сверить готовность рабочего места, имён, SSH, sudo и времени. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Свои значения подставлять не требуется. /etc/os-release — стандартный файл сведений об установленном Linux, а не путь к дистрибутиву Clearway CA. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Свои значения подставлять не требуется; команда используется в показанном виде. |
Где: Терминал Linux на рабочем месте оператора.
ca-video.example.test — имя учебного стенда; используйте имя своего сервиса.
Что подставить
| ca-video.example.test — Полное DNS-имя сервиса, разрешение которого нужно проверить с этой машины. Откуда взять: Из согласованной схемы DNS и поля Alias сервера в параметрах установки. В примере это учебное имя; подставьте имя своего сервиса. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Свои значения подставлять не требуется; команда используется в показанном виде. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Маска clearway-ca-installer_*.deb ищет пакеты инсталлятора в текущем каталоге; звёздочка обозначает изменяемую часть имени и остаётся в команде. Перейдите в папку с полученным пакетом или укажите путь к этой папке перед маской. |
Где: Терминал Linux на рабочем месте оператора.
Имя файла соответствует записи. Для другой поставки подставьте фактическое имя полученного пакета.
Что подставить
| ./clearway-ca-installer_2026.3.0~rc11-1_amd64.deb — Путь к полученному DEB-пакету, который будет установлен. Версия и архитектура входят в имя файла. Откуда взять: Возьмите фактическое имя из каталога, куда сохранён дистрибутив, например из вывода предыдущей команды ls. Префикс ./ означает текущий каталог; для другого расположения укажите полный путь. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Свои значения подставлять не требуется. clearway-ca-installer — имя установленного пакета, а не имя DEB-файла с версией. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| Свои значения подставлять не требуется. itc-installer — имя команды запуска; оно не заменяется именем сервера или путём к пакету. |
Где: Терминал Linux на рабочем месте оператора.
В браузере на том же рабочем месте открывается https://localhost:5224. Показанный вариант itc-installer cli — альтернативный консольный режим, в ролике он не запускается.
Что подставить
| Свои значения подставлять не требуется; команда используется в показанном виде. |
О чём ролик
Проходим быструю установку Clearway CA на одном сервере: задаём параметры центра сертификации, баз данных и администратора, подготавливаем зависимости и разворачиваем сервисы. Затем настраиваем доверие к корневому сертификату, входим в Контрольную панель, выпускаем первый сертификат и проверяем его имя и цепочку доверия.
Длительность
11:18
| Время | Действие |
|---|---|
| 00:00 | Результат быстрой установки. Развернуть корневой ЦС и основные сервисы и проверить выпуск сертификата. |
| 00:24 | Выбор быстрого сценария. Запустить установку компонентов на общей машине. |
| 00:51 | Подключение к серверу. Указать имя узла и SSH-реквизиты для развёртывания. |
| 01:17 | Параметры ЦС, баз данных и администратора. Задать Subject, алгоритм ключа, сервисное имя, пароли PostgreSQL и встроенную учётную запись. |
| 04:05 | Проверка и настройка зависимостей. Устранить отсутствующие пререквизиты до запуска установки. |
| 04:50 | Развёртывание компонентов. Выполнить установку и проконтролировать результаты шагов. |
| 05:23 | Доверие на клиентском компьютере. Разобрать, почему браузеру нужно доверять сертификатам ЦС и OpenID. |
| 05:57 | Импорт корневого сертификата в Windows. Добавить доверенный корневой сертификат в хранилище текущего пользователя. |
| 07:03 | Первый вход. Проверить работу аутентификации и открытие реестра сертификатов. |
| 07:37 | Подготовка CSR в конструкторе. Выбрать параметры ключа, Subject и SAN и получить команду OpenSSL. |
| 08:42 | Создание и проверка запроса. Создать закрытый ключ и CSR, затем проверить подпись запроса. |
| 08:58 | Выпуск сертификата в панели. Загрузить запрос, сверить параметры с шаблоном и выполнить выпуск. |
| 09:32 | Просмотр и скачивание результата. Проверить сведения в реестре и сохранить выпущенный сертификат. |
| 09:55 | Подготовка файлов для проверки. Скопировать и распаковать архив сертификатов. |
| 10:23 | Проверка реквизитов и доверия. Проверить Subject, издателя, SAN, назначение TLS-сервера и цепочку до корневого ЦС. |
| 10:51 | Что подтверждает успех. Убедиться, что вход работает, сертификат выпущен и проверка цепочки завершилась OK. |
Где: Терминал Linux на рабочем месте оператора.
Выполняется в том же shell перед openssl req.
Что подставить
| Свои значения подставлять не требуется. 077 — маска доступа для новых файлов: права группы и остальных пользователей отключены. Это не пароль и не идентификатор учётной записи. |
Где: Терминал Linux на рабочем месте оператора.
private.key — закрытый ключ, request.csr — запрос для передачи в ЦС. -nodes оставляет ключ без парольного шифрования; его права ограничиваются umask. Замените имя учебного сервиса своим.
Что подставить
| rsa:2048 — Алгоритм нового закрытого ключа и размер в битах. В показанном сценарии используется RSA 2048. Откуда взять: Сверьте разрешённый алгоритм и длину ключа в выбранном шаблоне сертификата и требованиях целевого сервиса. Если они совпадают с видео, оставьте rsa:2048. | |
| private.key — Имя выходного файла нового закрытого ключа, заданное после -keyout. Откуда взять: Выберите имя и каталог на машине владельца ключа. Сохраните этот файл для дальнейшей установки сертификата на сервис; в ЦС передаётся CSR, а не ключ. | |
| request.csr — Имя выходного файла запроса на сертификат, заданное после -out. Откуда взять: Выберите имя файла в рабочем каталоге. Этот же путь далее используется при проверке CSR и при загрузке запроса в Контрольную панель. | |
| demo-client.example.test — DNS-имя сервиса: оно входит в CN в -subj и в DNS-значение расширения subjectAltName. Замените оба вхождения согласованно. Откуда взять: Возьмите имя, по которому клиенты должны обращаться к сервису, из его конфигурации и согласованной DNS-схемы. Оно должно соответствовать требованиям выбранного шаблона. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| request.csr — Путь к проверяемому запросу на сертификат. Откуда взять: Используйте файл, созданный предыдущей командой openssl req в параметре -out. Если выбрали другое имя или каталог, укажите их здесь. |
Где: Терминал Linux на рабочем месте оператора.
Имя каталога загрузок зависит от языка и настроек рабочего места.
Что подставить
| ~/Загрузки/certificates.zip — Путь к ZIP-архиву сертификатов, скачанному из Контрольной панели. Откуда взять: Проверьте фактическую папку загрузок браузера и имя скачанного архива. ~ обозначает домашний каталог текущего пользователя; название папки может отличаться. | |
| . — Каталог назначения копирования; точка означает текущую рабочую папку. Откуда взять: Запустите команду из папки, где будете распаковывать и проверять сертификат, либо замените точку путём к выбранной папке. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| certificates.zip — Входной ZIP-архив для распаковки. Откуда взять: Укажите файл, скопированный на предыдущем шаге; при другом имени или расположении используйте фактический путь. | |
| issued — Папка, в которую будут извлечены файлы архива. Откуда взять: Выберите каталог результата. Затем используйте его имя как начало пути к сертификату в следующих командах. |
Где: Терминал Linux на рабочем месте оператора.
Что подставить
| issued/demo-client.example.test.cer — Путь к выпущенному конечному сертификату, сведения которого нужно прочитать. Откуда взять: Возьмите имя нужного файла из распакованного архива в каталоге issued. Имя сертификата в вашей загрузке может отличаться от показанного. |
Где: Терминал Linux на рабочем месте оператора.
../ca.crt — заранее полученный доверенный корневой сертификат. Используйте свой путь и DNS-имя.
Что подставить
| ../ca.crt — Доверенный корневой сертификат для построения и проверки цепочки. ../ указывает на каталог выше текущего. Откуда взять: Получите открытый корневой сертификат из доверенного источника: результатов установки своего корневого ЦС или от администратора PKI. Укажите фактический путь к сохранённому файлу. | |
| demo-client.example.test — Ожидаемое DNS-имя сервиса, которое OpenSSL сопоставляет с сертификатом в параметре -verify_hostname. Откуда взять: Используйте то имя, по которому клиенты подключаются к сервису. В этом сценарии оно совпадает с DNS-именем в CSR. | |
| issued/demo-client.example.test.cer — Проверяемый конечный сертификат. Откуда взять: Укажите путь к файлу из распакованного архива на предыдущем шаге. Не подставляйте сюда CSR, закрытый ключ или корневой сертификат. |
О чём ролик
Разворачиваем двухуровневую иерархию Clearway CA на двух серверах. Создаём корневой центр, получаем запрос выдающего центра, подписываем его на корневом ЦС, завершаем настройку выдающего и проверяем доступность обоих сервисов и цепочку доверия.
Длительность
09:18
| Время | Действие |
|---|---|
| 00:00 | Роли двух центров. Разделить задачи корневого и выдающего центров сертификации. |
| 00:23 | Имена серверов и сервисов. Сопоставить узлы video-root и video-issuing с сервисными именами root-ca и issuing-ca. |
| 00:57 | Расширенный сценарий установки ЦС. Начать развёртывание корневого центра. |
| 01:21 | Сервер и параметры корневого ЦС. Указать SSH-реквизиты, тип центра, Subject и алгоритм ключа. |
| 02:34 | Точка распространения. Определить размещение файлов сертификатов и списков отзыва. |
| 02:58 | База данных корневого ЦС. Настроить подключение к PostgreSQL. |
| 03:20 | Пререквизиты и развёртывание корня. Подготовить зависимости и проверить успешную установку. |
| 03:52 | Сохранение корневого сертификата. Передать в следующий этап открытый сертификат root-ca.crt; закрытый ключ остаётся на сервере. |
| 04:07 | Развёртывание выдающего ЦС. Указать второй сервер и тип «Выдающий ЦС», заполнить параметры и получить CSR. |
| 05:32 | Подпись запроса на корневом ЦС. Загрузить CSR выдающего центра в компонент «Выпуск сертификата» и получить подписанный сертификат. |
| 06:29 | Настройка выдающего ЦС. Загрузить корневой и выданный сертификаты, задать точку распространения и применить настройку. |
| 07:52 | Проверка API обоих центров. Выполнить mclient ping на корневом и выдающем серверах. |
| 08:29 | Проверка цепочки доверия. Получить сертификат выдающего ЦС и проверить его до доверенного корня. |
| 08:57 | Иерархия готова. Сохранить параметры и открытые сертификаты для подключения аутентификации и Контрольной панели. |
Где: Терминал корневого сервера.
Что подставить
| itc-svc — Технологическая учётная запись Linux, от имени которой установлены и запускаются компоненты ЦС. Откуда взять: Возьмите имя учётной записи из параметров развёртывания именно проверяемого центра. Если оно отличается, замените itc-svc в аргументе sudo -iu. | |
| /opt/itc/minica — Каталог установленного ЦС, в котором находится утилита mclient и её окружение. Откуда взять: Посмотрите путь установки в параметрах или истории развёртывания проверяемого сервера. Подставьте фактический каталог; относительный запуск ./mclient выполняется уже из него. |
Где: Терминал корневого сервера.
Сервисное имя, технологическая учётная запись и каталог должны соответствовать вашей установке.
Что подставить
| issuing-ca.example.test — Адрес сервера выдающего центра, к которому выполняется SSH-подключение. Откуда взять: Возьмите доступное имя или IP-адрес выдающего сервера из схемы размещения. В записи SSH-пользователь не указан: он определяется SSH-конфигурацией или текущим локальным именем. Если нужен другой, передайте пользователь@хост. Для подключения нужна учётная запись с sudo; она отличается от технологической itc-svc. | |
| itc-svc — Технологическая учётная запись Linux, от имени которой установлены и запускаются компоненты ЦС. Откуда взять: Возьмите имя учётной записи из параметров развёртывания именно проверяемого центра. Если оно отличается, замените itc-svc в аргументе sudo -iu. | |
| /opt/itc/minica — Каталог установленного ЦС, в котором находится утилита mclient и её окружение. Откуда взять: Посмотрите путь установки в параметрах или истории развёртывания проверяемого сервера. Подставьте фактический каталог; относительный запуск ./mclient выполняется уже из него. |
Где: Терминал с доступом к точке AIA.
Что подставить
| http://issuing-ca.example.test/aia/Clearway_Training_Issuing_CA.crt — Полный адрес опубликованного сертификата выдающего центра: схема, сервер, каталог AIA и имя файла. Откуда взять: Возьмите адрес CA Issuers из AIA конечного сертификата, выпущенного проверяемым выдающим центром, либо из настроек публикации сертификата этого центра. AIA самого выдающего сертификата может указывать на корневой. Меняться могут домен, путь и имя файла. | |
| issuing-ca.crt — Имя локального файла, в который curl сохранит скачанный сертификат. Откуда взять: Выберите имя и папку результата. Этот файл затем передаётся в openssl verify как проверяемый сертификат. |
Где: Каталог с root-ca.crt и issuing-ca.crt.
Что подставить
| root-ca.crt — Открытый доверенный корневой сертификат, которым проверяется цепочка выдающего ЦС. Откуда взять: Используйте файл, сохранённый после установки корневого центра и полученный из доверенного источника. При другом имени или расположении укажите полный путь. | |
| issuing-ca.crt — Сертификат выдающего центра, для которого проверяется цепочка. Откуда взять: Укажите файл, полученный предыдущей командой curl в параметре -o, либо тот же сертификат из результатов установки. |
О чём ролик
Разворачиваем Clearway OpenID и Контрольную панель, подключаем их к выдающему центру сертификации и задаём параметры аутентификации. Добавляем корневой сертификат в доверенные, проверяем адреса сервисов и выполняем первый вход со встроенной учётной записью.
Длительность
09:00
| Время | Действие |
|---|---|
| 00:00 | Назначение OpenID и Контрольной панели. Разделить аутентификацию пользователей и работу с центром сертификации. |
| 00:22 | Серверы, DNS-имена и подготовка. Сопоставить имена серверов video-auth и video-panel с адресами сервисов auth.example.test и panel.example.test. |
| 00:50 | Выбор компонента OpenID. Начать развёртывание сервиса аутентификации в расширенном режиме инсталлятора. |
| 01:01 | Сервер и параметры OpenID. Задать SSH-подключение, имя сервиса, технологическую учётную запись и каталог установки. |
| 01:45 | Подключение OpenID к центру сертификации. Указать существующий выдающий центр для выпуска служебного сертификата. |
| 02:10 | База данных OpenID. Настроить локальную базу cw-openid и её учётную запись. |
| 02:34 | Встроенная учётная запись. Подготовить вход admin@example.test до подключения внешнего каталога. |
| 02:50 | Издатель, токены и сессии. Задать канонический issuer и ограничения пользовательских сессий. |
| 03:30 | LDAP и проверка пререквизитов. Оставить LDAP выключенным, выполнить проверки и настройку недостающих компонентов. |
| 04:02 | Результат установки OpenID. Убедиться в успешном развёртывании сервиса аутентификации. |
| 04:08 | Развёртывание Контрольной панели. Выбрать компонент, сервер video-panel и имя сервиса panel.example.test. |
| 05:02 | Подключение панели к центру сертификации. Указать выдающий центр, его сертификат и отображаемое имя training-issuing. |
| 05:17 | Подключение панели к Clearway OpenID. Настроить внешний OpenID и тот же адрес издателя, что задан на сервере аутентификации. |
| 05:41 | Проверки и установка панели. Выполнить настройку пререквизитов и дождаться успешного развёртывания. |
| 06:03 | Доверие к корневому сертификату. Подготовить Windows к проверке HTTPS-сертификатов сервисов учебной инфраструктуры. |
| 06:22 | Импорт корневого сертификата в Windows. Добавить root-ca.crt в доверенные корневые сертификаты текущего пользователя. |
| 06:42 | Проверка OpenID и HTTPS панели. Проверить discovery-документ, issuer и доступность веб-интерфейса с проверкой цепочки сертификатов. |
| 07:35 | Первый вход и согласие на доступ. Войти со встроенной учётной записью и разрешить передачу данных Контрольной панели. |
| 08:11 | Реестр сертификатов и состояние центра. Проверить служебные сертификаты, выбранный центр сертификации и статус UP. |
| 08:39 | Итоги первого входа. Зафиксировать готовность панели и сервиса аутентификации к дальнейшей настройке. |
| 00:50 | Аутентификация (OpenID) → Развёртывание. Выбрать компонент в расширенном режиме. |
| 01:01 | SSH к video-auth.example.test. Подключиться учётной записью cwadmin. |
| 01:13 | Имя auth.example.test; itc-svc; /opt/itc. Задать сетевое имя сервиса и владельца его файлов. |
| 01:45 | Внешний центр сертификации: video-issuing.example.test. Указать SSH-доступ cwadmin, технологическую учётную запись itc-svc и каталог /opt/itc/minica. |
| 02:10 | Локальная БД cw-openid. Задать имя базы и пользователя cw-openid, ввести пароль. |
| 02:34 | Статическая учётная запись admin@example.test. Указать отображаемое имя admin и пароль для первого входа. |
| 02:50 | Настройка issuer и сроков действия. Итоговый issuer — https://auth.example.test/openid; id-токен — 5m, лимит сессий — 5, отклонение новой сессии при превышении лимита, refresh-токен — 24h, бездействие — 30m. |
| 03:30 | Интеграция с LDAP выключена. Сначала проверить работу встроенной учётной записи. |
| 03:43 | Проверки → настройка пререквизитов → развёртывание. Подготовить зависимости и установить Clearway OpenID. |
| 04:08 | Контрольная панель → Развёртывание. Установить панель на video-panel.example.test с SSH-пользователем cwadmin, именем panel.example.test, учётной записью itc-svc и каталогом /opt/itc. |
| 05:02 | Внешний центр и issuing-ca.crt. Указать video-issuing.example.test, загрузить сертификат выдающего центра и задать имя training-issuing. |
| 05:17 | Clearway Open ID; внешний OpenID. Указать video-auth.example.test, SSH-доступ и issuer https://auth.example.test/openid. |
| 05:41 | Проверки и развёртывание панели. Устранить недостающие пререквизиты и завершить установку. |
| 07:35 | Вход admin@example.test. Открыть панель, пройти аутентификацию и нажать «Предоставить доступ» на странице согласия. |
| 08:11 | Сертификаты → Статистика ЦС. Проверить сертификаты auth.example.test и panel.example.test и состояние выбранного центра сертификации. |
Где: Windows PowerShell, каталог C:\Clearway-Guide.
Ключ -user выбирает хранилище текущего пользователя. Файл root-ca.crt должен быть получен из доверенного источника.
Что подставить
| root-ca.crt — Путь к файлу доверенного корневого сертификата, который будет добавлен в хранилище Windows. Откуда взять: Возьмите корневой сертификат своего центра сертификации, подготовленный в предыдущих шагах курса и полученный из доверенного источника; подтвердите его отпечаток у администратора и укажите фактический путь к файлу на Windows. |
Где: Linux, video-auth, пользователь cwadmin, каталог ~/clearway-demo.
--cacert задаёт доверенный корневой сертификат для проверки HTTPS; jq выбирает три поля из JSON.
Что подставить
| ~/clearway-demo/root-ca.crt — Путь к корневому сертификату, используемому curl для проверки HTTPS-сертификата сервиса. Откуда взять: Укажите путь к проверенному корневому сертификату учебной цепочки или вашей инфраструктуры на Linux. В ролике файл заранее помещён в clearway-demo в домашнем каталоге; его не получают из проверяемого HTTPS-ответа. | |
| https://auth.example.test/openid/.well-known/openid-configuration — URL discovery-документа Clearway OpenID; auth.example.test — имя сервиса, /openid — путь издателя, /.well-known/openid-configuration — стандартный путь метаданных. Откуда взять: Возьмите канонический issuer, заданный в мастере OpenID, и добавьте /.well-known/openid-configuration. Подставьте свой адрес сервиса; схема и при необходимости порт должны соответствовать его настройке. |
Где: Linux, video-auth, пользователь cwadmin, каталог ~/clearway-demo.
-I запрашивает заголовки. В ролике получен HTTP/1.1 200 OK.
Что подставить
| ~/clearway-demo/root-ca.crt — Путь к корневому сертификату, используемому curl для проверки HTTPS-сертификата сервиса. Откуда взять: Укажите путь к проверенному корневому сертификату учебной цепочки или вашей инфраструктуры на Linux. В ролике файл заранее помещён в clearway-demo в домашнем каталоге; его не получают из проверяемого HTTPS-ответа. | |
| https://panel.example.test — HTTPS-адрес развёрнутой Контрольной панели. Откуда взять: Используйте имя сервиса панели, заданное в мастере установки и DNS; при нестандартном порте включите его в URL. |
О чём ролик
Подключаем Active Directory к Clearway OpenID через веб-мастер: задаём поиск пользователей и групп, атрибуты входа и стандартные группы ролей. Проверяем результат в Контрольной панели — администратор выпускает сертификат, а аудитор просматривает его карточку и связанные события.
Длительность
07:12
| Время | Действие |
|---|---|
| 00:00 | Вход через LDAP и проверка ролей. Определить сценарий подключения Active Directory и проверки фактических прав. |
| 00:25 | Учётные записи и группы учебного домена. Разобрать служебную учётную запись и группы CWCA_Administrator, CWCA_Auditor и CWCA_User. |
| 00:53 | Повторная настройка Clearway OpenID. Открыть компонент аутентификации в инсталляторе для подключения каталога. |
| 01:18 | Подключение к серверу LDAP. Включить интеграцию и задать адрес контроллера домена и bind-учётную запись. |
| 01:53 | Поиск пользователей и атрибуты входа. Настроить Base DN, фильтр и сопоставление LDAP-атрибутов с данными пользователя. |
| 02:39 | Имя входа, почта и отображаемое имя. Различить короткий логин ca.admin, адрес userPrincipalName и имя из displayName. |
| 02:46 | Поиск групп и членство. Настроить импорт групп, область поиска, фильтр и атрибут cn. |
| 03:09 | Группы и роли Clearway CA. Связать доменные группы с правами администратора и аудитора. |
| 03:36 | Применение параметров LDAP. Выполнить проверки и завершить развёртывание обновлённой конфигурации OpenID. |
| 03:58 | Вход доменного администратора. Выбрать LDAP и войти как ca.admin. |
| 04:24 | Доступ администратора к панели. Проверить реестр и доступность создания запроса сертификата. |
| 04:45 | Выпуск сертификата от администратора. Загрузить CSR, выбрать шаблон tls и выпустить сертификат ldap-admin.example.test. |
| 05:20 | Проверка выпущенного сертификата. Убедиться в успешном выпуске и запомнить RequestId 18 для проверки прав аудитора. |
| 05:37 | Смена пользователя. Завершить сеанс администратора и войти как ca.auditor. |
| 06:04 | Права аудитора в реестре и карточке. Проверить доступ к просмотру без элементов создания и отзыва сертификатов. |
| 06:31 | Просмотр событий по запросу. Найти события RequestId 18 и увидеть инициатора ca.admin. |
| 06:49 | Итоги проверки доменного доступа. Подтвердить различие прав ролей и необходимость нового входа после изменения групп. |
| 00:25 | Учётные записи в OU ClearwayGuide. svc.clearway используется для поиска в каталоге; ca.admin, ca.auditor и ca.user состоят в соответствующих группах CWCA_Administrator, CWCA_Auditor и CWCA_User. |
| 01:18 | Интеграция с LDAP. Задать dc01.example.test:389, DN CN=svc.clearway,OU=ClearwayGuide,DC=example,DC=test и пароль подключения. |
| 01:53 | Пользователи LDAP. Указать Base DN OU=ClearwayGuide,DC=example,DC=test и фильтр (objectClass=person); использовать sAMAccountName для логина, идентификатора и предпочитаемого имени, userPrincipalName для почты и displayName для отображаемого имени. |
| 02:46 | Группы LDAP. Включить импорт групп по запросу, указать тот же Base DN, фильтр (objectClass=group) и атрибут имени cn. |
| 02:54 | Членство в группах через member. Проверить, что группа содержит полный DN пользователя в атрибуте member. |
| 03:09 | CWCA_Administrator и CWCA_Auditor. Использовать стандартное сопоставление групп ролям для проверки разных наборов прав. |
| 03:36 | Далее → проверки → развёртывание. Применить настройки интеграции и проверить доступность LDAP. |
| 03:58 | Вход LDAP: ca.admin. Пройти аутентификацию и подтвердить предоставление доступа Контрольной панели. |
| 04:45 | Запрос сертификата. Загрузить request.csr, выбрать шаблон tls и проверить сведения запроса: CN и SAN ldap-admin.example.test, RSA 2048 и срок 365 дней. |
| 05:20 | Результат выпуска: RequestId 18. Проверить статус «Выпущен» у сертификата, запрошенного ca.admin. |
| 05:37 | Выход → вход LDAP: ca.auditor. Создать новый сеанс для проверки роли аудитора. |
| 06:04 | Просмотр реестра и карточки RequestId 18. Убедиться, что аудитор видит сертификат и его инициатора, но не получает действий выпуска и отзыва. |
| 06:31 | События → фильтр Request Id 18. Просмотреть события выпуска и подтвердить инициатора ca.admin. |
О чём ролик
Настраиваем сервис публикации и почасовую передачу полного CRL по SCP, затем проверяем доступность точек CDP и AIA из сертификата. С помощью curl и OpenSSL проверяем подпись и сроки списка отзыва, наличие отозванного сертификата в CRL и цепочку сертификата выдающего центра до доверенного корня.
Длительность
07:22
| Время | Действие |
|---|---|
| 00:00 | Зачем нужны сертификат центра и CRL. Разобрать построение цепочки доверия и публикацию сведений об отзыве. |
| 00:21 | План проверки публикации. Определить проверки доступности CDP и AIA, подписи, сроков и серийного номера. |
| 00:44 | Тестовый сертификат и его серийный номер. Выбрать publication-check.example.test и сохранить данные для проверки отзыва. |
| 01:04 | Подготовка файлов сертификатов. Подготовить publication-check.crt и доверенный root-ca.crt без использования закрытого ключа. |
| 01:11 | Извлечение CDP и AIA. Прочитать адреса CRL и сертификата выдающего центра из расширений сертификата. |
| 01:45 | Установка сервиса публикации. Развернуть компонент на сервере Контрольной панели с наследуемыми параметрами подключения. |
| 02:17 | Создание задачи публикации CRL. Открыть задачи публикации в Контрольной панели. |
| 02:26 | Полный CRL, формат DER и расписание. Создать issuing-crl-hourly с расписанием 0 * * * *. |
| 03:40 | Передача CRL по SCP. Задать сервер назначения, SSH-пользователя и полный путь публикуемого файла. |
| 04:16 | Карточка и первый запуск задачи. Проверить параметры и выполнить публикацию вне расписания. |
| 04:41 | Загрузка опубликованного CRL. Скачать файл по адресу CDP на клиентскую машину. |
| 04:59 | Подпись, издатель и сроки CRL. Проверить DER-список через OpenSSL и прочитать lastUpdate и nextUpdate. |
| 05:18 | Отзыв тестового сертификата. Отозвать сертификат с причиной CessationOfOperation. |
| 05:44 | Повторный запуск публикации. Запустить задачу после отзыва сертификата. |
| 05:56 | Поиск серийного номера в CRL. Найти отозванный сертификат, дату и причину отзыва в тексте списка. |
| 06:18 | Загрузка сертификата центра по AIA. Получить опубликованный сертификат выдающего центра. |
| 06:34 | Проверка цепочки до корневого центра. Проверить сертификат issuing-ca.crt с доверенным root-ca.crt. |
| 06:56 | Итоги проверки публикации. Подтвердить работу расписания и доступность материалов для проверки на клиенте. |
| 00:44 | Карточка publication-check.example.test. Проверить RequestId 5, шаблон tls и Serial Number 1000000000000000000004. |
| 01:04 | Сохранение открытого сертификата. Подготовить publication-check.crt; закрытый ключ для показанных проверок не требуется. |
| 01:45 | Сервис публикации → Развёртывание. Использовать сервер панели video-panel.example.test, SSH-пользователя cwadmin, технологическую учётную запись itc-svc и каталог /opt/itc. |
| 02:01 | Проверка пререквизитов и развёртывание. Проверить учётную запись, каталоги и Nginx, затем установить сервис публикации. |
| 02:17 | Задачи → Публикация CRL → Добавить задачу. Создать задачу для текущего центра сертификации training-issuing. |
| 02:26 | Параметры issuing-crl-hourly. Указать описание «Полный CRL выдающего центра», оставить Delta CRL выключенным, выбрать DER и расписание 0 * * * * — каждый час. |
| 03:40 | SCP. Включить SCP: хост issuing-ca.example.test, порт 22, пользователь cwadmin, пароль и путь /opt/itc/web/cdp/Clearway_Training_Issuing_CA.crl; локальное копирование и LDAP оставить выключенными. |
| 04:16 | Карточка задачи. Проверить тип base, центр training-issuing, расписание и параметры SCP. |
| 04:27 | Выполнить → Подтвердить. Запустить публикацию сразу, не дожидаясь расписания. |
| 05:30 | Отозвать: CessationOfOperation. Отозвать тестовый сертификат; переключатель Delta CRL в диалоге оставлен выключенным. |
| 05:44 | Повторное выполнение issuing-crl-hourly. Опубликовать список после отзыва и дождаться уведомления об успешном выполнении задачи. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
-noout скрывает полный сертификат; -ext выбирает два расширения.
Что подставить
| publication-check.crt — Входной файл открытого тестового сертификата, из которого читаются CDP и AIA. Откуда взять: Сохраните сертификат из карточки publication-check.example.test на предыдущем шаге (01:04) и укажите своё имя файла. Закрытый ключ для этой команды не нужен. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
-f завершает запрос с ошибкой при ошибочном HTTP-статусе; -o задаёт имя выходного файла.
Что подставить
| http://issuing-ca.example.test/cdp/Clearway_Training_Issuing_CA.crl — Полный URL файла CRL, опубликованного выдающим центром. Откуда взять: Скопируйте адрес из расширения CRL Distribution Points, выведенного командой на 01:11; домен и имя файла должны соответствовать вашему сертификату и точке публикации. | |
| issuing-ca.crl — Имя выходного файла скачанного списка отзыва. Откуда взять: Выберите имя и каталог локальной копии CRL; укажите тот же путь в обеих следующих командах openssl crl. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
В кадре результат verify OK. Файл issuing-ca.crt уже должен быть доступен локально; его загрузка по AIA показана позднее.
Что подставить
| issuing-ca.crl — Локальный файл полного списка отзыва в формате DER. Откуда взять: Для первичной проверки используйте файл, скачанный командой curl на 04:41; после новой публикации скачайте актуальную копию по тому же CDP. Если выбрали другое имя выходного файла, подставьте его. | |
| issuing-ca.crt — Файл сертификата выдающего центра, которым проверяется подпись CRL. Откуда взять: Заранее получите сертификат центра, подписавшего CRL, у администратора или из точки AIA и проверьте его цепочку. В монтаже скачивание этого файла по AIA показано позже — на 06:18. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
Показана причина Cessation Of Operation. Команда читает локальный файл; после новой публикации его нужно обновить, однако повторное скачивание в монтаже не показано.
Что подставить
| issuing-ca.crl — Локальный файл полного списка отзыва в формате DER. Откуда взять: Для первичной проверки используйте файл, скачанный командой curl на 04:41; после новой публикации скачайте актуальную копию по тому же CDP. Если выбрали другое имя выходного файла, подставьте его. | |
| 1000000000000000000004 — Серийный номер отозванного тестового сертификата, который grep ищет в тексте CRL. Откуда взять: Возьмите Serial Number из карточки своего отозванного сертификата (в ролике RequestId 5) и приведите его к шестнадцатеричному представлению OpenSSL без разделителей. Это серийный номер сертификата, а не RequestId. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
Используется адрес CA Issuers, прочитанный из расширения authorityInfoAccess.
Что подставить
| http://issuing-ca.example.test/aia/Clearway_Training_Issuing_CA.crt — Полный URL сертификата выдающего центра в точке AIA CA Issuers. Откуда взять: Скопируйте адрес CA Issuers из расширения authorityInfoAccess, выведенного командой на 01:11; используйте URL именно того центра, который выдал проверяемый сертификат. | |
| issuing-ca.crt — Имя выходного файла сертификата выдающего центра. Откуда взять: Выберите имя локального файла; затем используйте тот же путь в команде openssl verify и при проверке подписи CRL. |
Где: Linux, video-root, пользователь cwadmin, каталог ~/clearway-demo/chapter06.
В кадре результат issuing-ca.crt: OK. Эта команда проверяет сертификат центра, а не статус отзыва тестового конечного сертификата.
Что подставить
| ../root-ca.crt — Путь к доверенному корневому сертификату, относительно которого проверяется цепочка выдающего центра. Откуда взять: Используйте корневой сертификат, подготовленный на предыдущих шагах курса и проверенный по доверенному источнику. В примере он лежит на каталог выше chapter06; подставьте фактический путь в своей системе. | |
| issuing-ca.crt — Входной файл сертификата выдающего центра, цепочку которого нужно проверить. Откуда взять: Используйте файл, скачанный по AIA предыдущей командой на 06:18; если выбрали другое имя после -o, подставьте его. |
О чём ролик
Разворачиваем OCSP на сервере выдающего центра сертификации и подключаем ответчик к его рабочей базе. Создаём отдельный учебный сертификат, проверяем подписанный ответ GOOD, отзываем сертификат и повторяем запрос до получения REVOKED. В конце проверяем адрес OCSP, записанный в сертификате.
Длительность
08:15
| Время | Действие |
|---|---|
| 00:00 | Что проверяем: GOOD → REVOKED. Один учебный сертификат и два подписанных ответа. |
| 00:23 | Схема размещения OCSP. Выдающий центр, его рабочая БД и адрес ответчика. |
| 00:54 | Установка сервиса в веб-мастере. Выбор OCSP, сервер и основные параметры. |
| 01:47 | Подключение к центру сертификации и БД. Параметры выпуска сертификата ответчика и рабочей БД. |
| 02:48 | Проверка пререквизитов и развёртывание. Проверки, установка и успешный результат. |
| 03:18 | Создание ключа и запроса CSR. Подготовка ocsp-client.example.test через OpenSSL. |
| 04:00 | Выпуск учебного сертификата. Отправка CSR и просмотр выпущенного сертификата. |
| 04:34 | Проверка реквизитов сертификата. Subject, серийный номер и сроки действия. |
| 04:59 | Первый запрос OCSP: GOOD. Проверка подписи и сохранение ответа good.der. |
| 06:03 | Отзыв сертификата. Отзыв с причиной CessationOfOperation через Контрольную панель. |
| 06:34 | Повторный запрос: REVOKED. Проверка причины и времени отзыва; сохранение revoked.der. |
| 07:07 | Проверка адреса OCSP в сертификате. Чтение OCSP URI и итог проверки. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
Что подставить
| Свои значения подставлять не требуется: 077 — показанная маска, запрещающая доступ группы и остальных пользователей к новым файлам ключа. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
-nodes сохраняет ключ без парольного шифрования; это команда учебного ролика.
Что подставить
| rsa:2048 — Тип создаваемого ключа RSA и его длина 2048 бит. Откуда взять: Выберите алгоритм и длину, разрешённые шаблоном выпуска и требованиями вашего центра; здесь показан учебный вариант RSA 2048. | |
| ocsp-client.key — Имя выходного файла нового закрытого ключа. Откуда взять: Выберите имя и путь в подготовленном защищённом каталоге клиента; этот файл создаёт команда. | |
| ocsp-client.csr — Имя выходного файла запроса на сертификат. Откуда взять: Выберите имя и путь для CSR, который затем загрузите при выпуске сертификата. | |
| ocsp-client.example.test — Значение Common Name в Subject запроса после /CN=. Откуда взять: Возьмите имя проверяемого клиента или сервиса из его DNS-конфигурации и требований выбранного шаблона сертификата. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
Что подставить
| ocsp-client.crt — Файл сертификата клиента, статус которого проверяется. Откуда взять: Скачайте выпущенный по CSR сертификат из карточки в Контрольной панели и укажите путь к сохранённому файлу. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
В ролике ответ good и Response verify OK.
Что подставить
| issuing-ca.crt — Сертификат центра, непосредственно выпустившего проверяемый сертификат; нужен для формирования OCSP-запроса. Откуда взять: Возьмите сертификат выдающего центра из результата его развёртывания или из подготовленной цепочки проверяемого сертификата. | |
| ocsp-client.crt — Файл сертификата клиента, статус которого проверяется. Откуда взять: Скачайте выпущенный по CSR сертификат из карточки в Контрольной панели и укажите путь к сохранённому файлу. | |
| http://ocsp.example.test:8888/ocsp — Полный адрес OCSP: схема HTTP, имя ответчика, порт 8888 и путь /ocsp в учебном стенде. Откуда взять: Возьмите OCSP URI из проверяемого сертификата либо полный согласованный адрес и порт из конфигурации развёрнутого OCSP-сервиса. | |
| ca-chain.pem — PEM-файл доверенной цепочки для проверки подписи OCSP-ответа. Откуда взять: Подготовьте файл из доверенных сертификатов вашей иерархии, полученных при развёртывании центров или от администратора центра. | |
| good.der — Выходной файл DER с OCSP-ответом до отзыва. Откуда взять: Выберите имя и путь для сохранения первого ответа; они не должны совпадать с файлом ответа после отзыва. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
В ролике revoked, Reason: cessationOfOperation и Response verify OK.
Что подставить
| issuing-ca.crt — Сертификат центра, непосредственно выпустившего проверяемый сертификат; нужен для формирования OCSP-запроса. Откуда взять: Возьмите сертификат выдающего центра из результата его развёртывания или из подготовленной цепочки проверяемого сертификата. | |
| ocsp-client.crt — Файл сертификата клиента, статус которого проверяется. Откуда взять: Скачайте выпущенный по CSR сертификат из карточки в Контрольной панели и укажите путь к сохранённому файлу. | |
| http://ocsp.example.test:8888/ocsp — Полный адрес OCSP: схема HTTP, имя ответчика, порт 8888 и путь /ocsp в учебном стенде. Откуда взять: Возьмите OCSP URI из проверяемого сертификата либо полный согласованный адрес и порт из конфигурации развёрнутого OCSP-сервиса. | |
| ca-chain.pem — PEM-файл доверенной цепочки для проверки подписи OCSP-ответа. Откуда взять: Подготовьте файл из доверенных сертификатов вашей иерархии, полученных при развёртывании центров или от администратора центра. | |
| revoked.der — Выходной файл DER с OCSP-ответом после отзыва. Откуда взять: Выберите отдельное имя и путь для второго ответа, чтобы сохранить оба результата проверки. |
Где: Linux, терминал cwadmin@video-root, каталог ocsp-demo.
Что подставить
| ocsp-client.crt — Файл сертификата клиента, статус которого проверяется. Откуда взять: Скачайте выпущенный по CSR сертификат из карточки в Контрольной панели и укажите путь к сохранённому файлу. |
О чём ролик
Устанавливаем архиватор на сервер выдающего центра и задаём рабочую и архивную базы PostgreSQL. Проверяем условия переноса, временно меняем срок и расписание для учебного запуска, затем сверяем журнал и записи в обеих базах. После проверки возвращаем обычное ежедневное расписание и исходные сроки.
Длительность
07:05
| Время | Действие |
|---|---|
| 00:00 | Установка и контрольная выборка. Что проверяется до и после переноса. |
| 00:25 | Рабочая и архивная базы. Источник cwi-ca и назначение cwi-ca-archive. |
| 00:51 | Установка через веб-мастер. Сервер, рабочая БД, архивная БД и сроки переноса. |
| 02:08 | Пререквизиты и развёртывание. Подготовка PostgreSQL, каталогов и службы архиватора. |
| 02:54 | Условия переноса. CertificateDays = 30, EventDays = 50 и связи объектов. |
| 03:09 | Учебная выборка событий 11–14. Проверка возраста и отсутствия связей по выбранным полям. |
| 03:26 | Проверка конфигурации. Просмотр расписания и сроков через jq. |
| 03:51 | Проверка исходных записей в PostgreSQL. Выборка четырёх событий до переноса. |
| 04:28 | Временные настройки для демонстрации. Копия конфигурации, EventDays = 1 и частое расписание. |
| 05:00 | Проверка JSON и перезапуск службы. Применение настроек и статус active. |
| 05:30 | Проверка журнала переноса. Вставка и удаление 22 событий. |
| 05:54 | Сверка рабочей и архивной баз. 0 выбранных записей в источнике и 4 в архиве. |
| 06:18 | Возврат исходных настроек. @daily, CertificateDays = 30, EventDays = 50. |
| 06:36 | Итог проверки. Установка, перенос и возврат параметров подтверждены. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| Свои значения подставлять не требуется: pwd выводит текущий каталог; сначала перейдите в каталог конфигурации вашей установки архиватора. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| Key, Cron, CertificateDays и EventDays — имена полей JSON, их не заменяют именами своих параметров. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| postgres — Учётная запись Linux для запуска локального psql; без отдельного имени роли psql использует соответствующее имя PostgreSQL. Откуда взять: Возьмите служебную учётную запись установленного PostgreSQL с доступом к нужной БД; в показанной стандартной установке это postgres. | |
| cwi-ca — Имя рабочей БД центра, из которой архиватор переносит записи. Откуда взять: Возьмите имя из параметров рабочей БД центра и источника задачи в конфигурации архиватора. | |
| pager=off — фиксированная настройка вывода без постраничного просмотра; пользовательские данные вместо off не нужны. |
Где: psql, база cwi-ca.
Что подставить
| 11 — Нижняя граница включительного диапазона идентификаторов событий для контрольной выборки. Откуда взять: Возьмите первый ID из предварительно выбранных событий вашей рабочей БД; запишите его для одинаковой проверки источника и архива. | |
| 14 — Верхняя граница включительного диапазона идентификаторов событий. Откуда взять: Возьмите последний ID той же контрольной выборки в рабочей БД; используйте одинаковые границы во всех последующих SELECT. | |
| evt и имена SQL-колонок относятся к показанной схеме данных; timestamp(0) задаёт вывод времени без долей секунды и не является ID для подстановки. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| itc_api_miniCA_archiver_config.json.before-video — Путь к резервной копии конфигурации до редактирования. Откуда взять: Выберите отдельное имя для копии в доступном каталоге, отличное от исходного файла; суффикс before-video — имя из демонстрации. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
В ролике временно EventDays = 1 и Cron = "* * * * *"; затем исходные значения восстановлены.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| В открытом JSON пользователь задаёт EventDays (возраст событий и запросов в днях) и Cron (расписание). Источник значений — согласованные сроки хранения и расписание; в учебном запуске временно указаны 1 и * * * * *, затем восстановлены 50 и @daily. Эти значения вводятся в редакторе, а не подставляются в строку nano. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| empty — программа проверки jq, а JSON: OK — текст сообщения об успешной проверке; свои значения вместо них не требуются. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
1001 — UID технологической учётной записи в показанном стенде.
Что подставить
| itc-svc — Технологическая учётная запись Linux, от имени которой запущен архиватор. Откуда взять: Возьмите имя из параметров развёртывания архиватора и владельца его пользовательской службы. | |
| /run/user/1001 — Каталог среды выполнения пользовательской службы; 1001 — числовой UID технологической учётной записи. Откуда взять: Определите UID выбранной учётной записи по выводу id на сервере и используйте её фактический каталог /run/user/<UID>. UID 1001 из стенда не переносится автоматически. | |
| archiver.service — стандартное имя пользовательской службы архиватора в этой установке; его сохраняют при такой же установке. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| itc-svc — Технологическая учётная запись Linux, от имени которой запущен архиватор. Откуда взять: Возьмите имя из параметров развёртывания архиватора и владельца его пользовательской службы. | |
| /run/user/1001 — Каталог среды выполнения пользовательской службы; 1001 — числовой UID технологической учётной записи. Откуда взять: Определите UID выбранной учётной записи по выводу id на сервере и используйте её фактический каталог /run/user/<UID>. UID 1001 из стенда не переносится автоматически. | |
| archiver.service — стандартное имя той же службы, состояние которой проверяется после перезапуска. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Имя файла и Count==22 относятся к записи демонстрации.
Что подставить
| 22 — Число записей переноса, по которому фильтруются сообщения журнала; это не количество событий выбранного диапазона 11–14. Откуда взять: Возьмите фактическое значение Count из сообщений нужного запуска архиватора в журнале. | |
| /opt/itc/archiver/itc/logs/itc_api_miniCA_archiver/itc_api_miniCA_archiver_log-20261011.ndjson — Полный путь к журналу нужного запуска; 20261011 — дата файла в формате ГГГГММДД из записи демонстрации. Откуда взять: Возьмите каталог журналов установленного архиватора и файл за дату проверяемого запуска; используйте фактическое имя файла, а не дату учебного стенда. | |
| .time[0:19] задаёт срез строки времени для вывода; это фиксированные индексы форматирования, не идентификаторы событий. |
Где: psql, база cwi-ca.
В ролике count = 0.
Что подставить
| 11 — Нижняя граница включительного диапазона идентификаторов событий для контрольной выборки. Откуда взять: Возьмите первый ID из предварительно выбранных событий вашей рабочей БД; запишите его для одинаковой проверки источника и архива. | |
| 14 — Верхняя граница включительного диапазона идентификаторов событий. Откуда взять: Возьмите последний ID той же контрольной выборки в рабочей БД; используйте одинаковые границы во всех последующих SELECT. |
Где: psql.
Что подставить
| cwi-ca-archive — Имя архивной БД, на которую переключается текущий сеанс psql. Откуда взять: Возьмите имя из назначения задачи архиватора и параметров архивной БД, заданных при развёртывании. |
Где: psql, база cwi-ca-archive.
В ролике возвращены ID 11–14.
Что подставить
| 11 — Нижняя граница включительного диапазона идентификаторов событий для контрольной выборки. Откуда взять: Возьмите первый ID из предварительно выбранных событий вашей рабочей БД; запишите его для одинаковой проверки источника и архива. | |
| 14 — Верхняя граница включительного диапазона идентификаторов событий. Откуда взять: Возьмите последний ID той же контрольной выборки в рабочей БД; используйте одинаковые границы во всех последующих SELECT. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Итоговые значения: @daily, CertificateDays = 30, EventDays = 50.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| itc-svc — Технологическая учётная запись Linux, от имени которой запущен архиватор. Откуда взять: Возьмите имя из параметров развёртывания архиватора и владельца его пользовательской службы. | |
| /run/user/1001 — Каталог среды выполнения пользовательской службы; 1001 — числовой UID технологической учётной записи. Откуда взять: Определите UID выбранной учётной записи по выводу id на сервере и используйте её фактический каталог /run/user/<UID>. UID 1001 из стенда не переносится автоматически. | |
| В редакторе восстановите Cron, CertificateDays и EventDays из сохранённой исходной конфигурации и принятой политики хранения. В ролике итоговые значения: @daily, 30 и 50. archiver.service — стандартная служба архиватора. |
Где: Linux, cwadmin@video-issuing; каталог /opt/itc/archiver/itc/config.
Что подставить
| itc_api_miniCA_archiver_config.json — Файл конфигурации архиватора; относительное имя ищется в текущем каталоге. Откуда взять: Возьмите файл из каталога установленного архиватора. В ролике это /opt/itc/archiver/itc/config; используйте фактический путь вашей установки. | |
| Cron, CertificateDays и EventDays — фиксированные имена полей JSON. Сравнивайте их значения с исходной копией конфигурации и согласованной политикой хранения. |
О чём ролик
Устанавливаем сервис резервного копирования на сервер Контрольной панели. Создаём задание для базы данных и узла выдающего центра, задаём расписание и состав файлов. Запускаем первую копию вручную и проверяем завершение задания и отметку «Пригодна».
Длительность
04:17
| Время | Действие |
|---|---|
| 00:00 | План: сервис, задание, первая копия. Исходное условие — установленная Контрольная панель. |
| 00:17 | Выбор сервиса резервного копирования. Компонент веб-мастера и унаследованные настройки сервера. |
| 00:49 | Проверки и развёртывание. Зависимости, каталоги и утилиты PostgreSQL. |
| 01:38 | Открытие резервного копирования в панели. Переход к списку заданий. |
| 01:45 | Новое задание и параметры БД. Ключ, описание, Cron и подключение к cwi-ca. |
| 02:07 | Узел центра сертификации. Исполняемый файл, systemd, пользователь, SSH и файлы конфигурации. |
| 02:49 | Сохранение и проверка задания. Просмотр состава созданного задания issuing-training. |
| 03:03 | Ручной запуск копирования. Запуск задания и ожидание окончания. |
| 03:34 | Проверка результата. Архив создан; интерфейс показывает «Пригодна». |
| 03:57 | Дальнейшее хранение и восстановление. Копии вне сервера и проверка восстановления на отдельном стенде. |
О чём ролик
Устанавливаем адаптер SCEP через веб-мастер и проверяем получение сертификата с отдельного Linux-клиента. Подготавливаем доверенные сертификаты и Certmonger, регистрируем SCEP-службу, получаем одноразовый пароль и создаём запрос. Завершаем проверкой статуса MONITORING, отсутствия ошибки stuck и наличия сертификата клиента.
Длительность
07:19
| Время | Действие |
|---|---|
| 00:00 | Сценарий установки и запроса. Адаптер на сервере выдающего центра, отдельный Linux-клиент. |
| 00:19 | Выбор SCEP и параметры сервера. Подключение к целевому серверу и основные параметры. |
| 01:13 | Центр сертификации, БД и аутентификация. Настройка зависимостей адаптера. |
| 02:38 | Пререквизиты и развёртывание. Проверки и установка SCEP. |
| 03:04 | Подготовка Certmonger. Установка пакета на Linux-клиенте. |
| 03:27 | Каталог клиента и доверие корневому сертификату. Права каталога и установка root-ca.pem в системное доверие. |
| 04:05 | Открытые сертификаты для клиента. root-ca.pem, issuing-ca.pem и scep-ra.pem. |
| 04:29 | Регистрация SCEP-службы в Certmonger. getcert add-scep-ca и list-cas. |
| 04:59 | Получение одноразового пароля. Запрос challenge-password с токеном и проверка прав файла. |
| 05:32 | Запрос сертификата. Создание ключа и запрос с одноразовым паролем. |
| 06:33 | Проверка результата в Certmonger. MONITORING, stuck: no и реквизиты сертификата. |
| 07:03 | Итог: сертификат получен. Новый одноразовый пароль нужен для следующего запроса. |
Где: Linux-клиент, root@video-auth.
Показанная команда установки пакета.
Что подставить
| Свои значения подставлять не требуется: certmonger — имя устанавливаемого пакета в показанном Linux-дистрибутиве, а -y подтверждает его установку. |
Где: Linux-клиент, root@video-auth.
Что подставить
| /root/scep-ch10/private — Создаваемый каталог закрытых ключей клиента. Откуда взять: Выберите постоянный каталог на клиенте, доступный владельцу ключа и Certmonger; его путь затем используется при создании файла ключа. | |
| 700 — показанные права каталога: доступ только владельцу. Это защитная настройка, её не заменяют именем пользователя или файла. |
Где: Linux-клиент, root@video-auth.
Исходный путь соответствует учебному стенду.
Что подставить
| /home/cwadmin/ch10-client-20261009/root-ca.crt — Исходный файл доверенного корневого сертификата; cwadmin и дата каталога относятся к стенду. Откуда взять: Возьмите фактический путь к файлу корневого сертификата, полученному от администратора или из результата развёртывания вашей иерархии. | |
| /root/scep-ch10/root-ca.pem — Путь назначения для копии корневого сертификата на клиенте. Откуда взять: Выберите имя файла в подготовленном рабочем каталоге клиента и затем используйте этот же путь в командах SCEP. | |
| 644 — показанные права открытого сертификата: запись владельцу, чтение остальным. install копирует файл, но не преобразует его формат; исходный файл должен содержать PEM-сертификат. |
Где: Linux-клиент, root@video-auth.
Что подставить
| /root/scep-ch10/root-ca.pem — Полный путь к доверенному корневому сертификату PEM на SCEP-клиенте. Откуда взять: Используйте путь к копии корневого сертификата, подготовленной предыдущим шагом из проверенного файла вашей иерархии. | |
| /usr/local/share/ca-certificates/clearway-root-ca.crt — Путь назначения для добавления корневого сертификата в локальное системное доверие. Откуда взять: В показанном дистрибутиве выберите уникальное имя с расширением .crt в /usr/local/share/ca-certificates; используйте проверенный корневой сертификат своей иерархии. | |
| 644 — фиксированные права открытого сертификата в этом примере; update-ca-certificates выполняется следующим шагом. |
Где: Linux-клиент, root@video-auth.
Что подставить
| Свои значения подставлять не требуется: команда обновляет системное доверие из установленных файлов сертификатов. |
Где: Linux-клиент, root@video-auth.
Что подставить
| Clearway-SCEP — Локальное имя подключения к SCEP-адаптеру в Certmonger. Откуда взять: При регистрации выберите понятное уникальное имя; затем используйте то же имя в list-cas и request. | |
| https://scep.example.test/api/scep/v1/scep — Полный внешний URL SCEP-адаптера, включая схему HTTPS, DNS-имя и опубликованный путь. Откуда взять: Возьмите адрес из конфигурации опубликованного SCEP-адаптера вашей установки. Скопируйте его целиком: путь вашей версии может отличаться от пути в видео. | |
| /root/scep-ch10/root-ca.pem — Полный путь к доверенному корневому сертификату PEM на SCEP-клиенте. Откуда взять: Используйте путь к копии корневого сертификата, подготовленной предыдущим шагом из проверенного файла вашей иерархии. | |
| /root/scep-ch10/issuing-ca.pem — Полный путь к PEM-сертификату выдающего центра, используемому SCEP-адаптером. Откуда взять: Получите у администратора открытый сертификат того центра, который выпускает сертификаты через ваш SCEP-адаптер, и заранее сохраните его в PEM на клиенте. Набор подготовленных сертификатов показан на 04:05; укажите свой постоянный полный путь к этому файлу. | |
| /root/scep-ch10/scep-ra.pem — Полный путь к PEM-сертификату SCEP-адаптера (RA). Откуда взять: Получите у администратора открытый сертификат RA именно вашего SCEP-адаптера и заранее сохраните его в PEM на клиенте. Набор подготовленных сертификатов показан на 04:05; укажите свой постоянный полный путь. Это не сертификат конечного клиента. |
Где: Linux-клиент, root@video-auth.
Что подставить
| Clearway-SCEP — Локальное имя подключения к SCEP-адаптеру в Certmonger. Откуда взять: При регистрации выберите понятное уникальное имя; затем используйте то же имя в list-cas и request. |
Где: Linux-клиент, root@video-auth, каталог /root/scep-ch10.
В $TOKEN должен быть действующий токен; его получения этот фрагмент не показывает.
Что подставить
| root-ca.pem — Файл доверенного корневого сертификата для проверки HTTPS; относительное имя ищется в текущем каталоге. Откуда взять: Используйте корневой сертификат, подготовленный ранее в рабочем каталоге /root/scep-ch10, либо укажите фактический путь к нему. | |
| $TOKEN — Переменная оболочки с действующим токеном доступа OpenID для получения одноразового пароля. Откуда взять: Получите токен у провайдера OpenID, подключённого к вашему SCEP-адаптеру, для пользователя с правом выпуска и заранее сохраните его в переменную TOKEN в текущей оболочке. Способ получения токена в этом фрагменте не показан. | |
| https://scep.example.test/api/scep/v1/scep/challenge-password — URL выдачи одноразового пароля; это адрес SCEP-службы с окончанием /challenge-password. Откуда взять: Возьмите полный внешний адрес вашей SCEP-службы из её опубликованной конфигурации и адрес операции challenge-password для этой установки. | |
| challenge.txt — Выходной файл с полученным одноразовым паролем. Откуда взять: Выберите файл в защищённом рабочем каталоге клиента; тот же файл затем передайте Certmonger. Его содержимое возвращает SCEP-адаптер, вручную придумывать пароль не нужно. | |
| umask 077 оставляет новый файл пароля доступным только владельцу. Authorization: Bearer — фиксированный формат заголовка; меняется значение токена в TOKEN. |
Где: Linux-клиент, root@video-auth, каталог /root/scep-ch10.
В ролике: 600 root challenge.txt.
Что подставить
| challenge.txt — Проверяемый файл одноразового пароля. Откуда взять: Укажите тот же файл, в который предыдущая команда curl сохранила challenge. | |
| %a %U %n — фиксированный формат вывода прав, владельца и имени файла; свои данные вместо этих кодов не нужны. |
Где: Linux-клиент, root@video-auth.
Параметр -l — строчная латинская L; он задаёт файл challenge.
Что подставить
| Clearway-SCEP — Локальное имя подключения к SCEP-адаптеру в Certmonger. Откуда взять: При регистрации выберите понятное уникальное имя; затем используйте то же имя в list-cas и request. | |
| scep-client — Локальное имя задачи Certmonger после -I; это не серийный номер сертификата. Откуда взять: Выберите уникальное имя задачи на этом клиенте и сохраните его для последующего getcert list -i. | |
| RSA — Алгоритм создаваемого ключа клиента. Откуда взять: Выберите алгоритм, поддерживаемый Certmonger и разрешённый настройками выпуска SCEP вашей установки; в ролике используется RSA. | |
| 2048 — Длина создаваемого RSA-ключа в битах. Откуда взять: Возьмите допустимую длину из требований к сертификатам и шаблона, используемого SCEP-адаптером; здесь выбрано 2048. | |
| /root/scep-ch10/private/scep-client.key — Путь выходного файла нового закрытого ключа. Откуда взять: Выберите имя файла в ранее созданном защищённом каталоге ключей; укажите постоянный путь, доступный Certmonger. | |
| /root/scep-ch10/scep-client.crt — Путь, по которому Certmonger сохранит выданный сертификат клиента. Откуда взять: Выберите имя файла сертификата в рабочем каталоге клиента; затем проверяйте результат по этому пути. | |
| CN=scep-client.example.test — Subject запроса: Common Name клиента после -N. Откуда взять: Возьмите имя клиента или сервиса из его DNS-конфигурации и правил используемого шаблона; сохраните синтаксис CN= перед своим именем. | |
| scep-client.example.test — DNS-имя Subject Alternative Name после -D; в видео оно совпадает с Common Name. Откуда взять: Возьмите фактическое DNS-имя, по которому будет использоваться сертификат клиента, и проверьте его соответствие разрешённым именам шаблона. | |
| /root/scep-ch10/challenge.txt — Файл одноразового пароля, передаваемый после строчной -l. Откуда взять: Возьмите полный путь к файлу challenge, сохранённому предыдущей командой curl; для нового запроса нужен действующий неиспользованный пароль. | |
| 90 — Максимальное время ожидания результата команды в секундах. Откуда взять: Выберите допустимое время ожидания для своей проверки; в ролике 90 секунд. Истечение ожидания само по себе не отменяет задачу Certmonger. |
Где: Linux-клиент, root@video-auth.
В ролике status: MONITORING и stuck: no.
Что подставить
| scep-client — Имя проверяемой задачи Certmonger после -i. Откуда взять: Возьмите точное имя, заданное после -I при getcert request на этом клиенте. |
О чём ролик
Устанавливаем адаптер MS-WSTEP с двумя службами CEP/CES и параметрами подключения к центру сертификации и Active Directory. На доменном компьютере Windows добавляем политику регистрации и запрашиваем сертификат по шаблону tls. Проверяем статус Issued, размещение в хранилище компьютера и наличие закрытого ключа.
Длительность
04:52
| Время | Действие |
|---|---|
| 00:00 | Исходные условия и результат. Подготовлены домен, доверие, действующий центр и шаблон tls. |
| 00:27 | Выбор MS-WSTEP. Начало установки адаптера. |
| 00:34 | Назначение CEP и CES. Политика регистрации и приём запросов Windows. |
| 00:47 | Сервер и основные параметры. Подключение, alias и путь установки. |
| 01:32 | Подключение к центру сертификации. Реквизиты ЦС и его сертификат. |
| 02:03 | Параметры Active Directory. LDAP-сервер, домен, базовый DN и учётные записи. |
| 02:53 | Пререквизиты и развёртывание. Проверка домена и установка служб. |
| 03:21 | Политика регистрации Windows. Добавление CEP с Kerberos для компьютера. |
| 03:53 | Запрос сертификата Windows. Шаблон tls и хранилище LocalMachine/My. |
| 04:18 | Статус Issued. Проверка успешной выдачи. |
| 04:23 | Реквизиты выданного сертификата. Subject, издатель, отпечаток, срок и HasPrivateKey. |
Где: Windows, PowerShell на доменном компьютере WS01, C:\Clearway-Guide.
В выводе AuthType: Kerberos, Context: Machine.
Что подставить
| https://wstep.example.test/CEP_Kerberos/service.svc/CEP — Полный HTTPS-адрес службы политики регистрации CEP с Kerberos. Откуда взять: Возьмите DNS-alias сервиса MS-WSTEP и опубликованный URL CEP из результатов его развёртывания; используйте один и тот же адрес при регистрации политики и запросе сертификата. | |
| Machine — фиксированное значение контекста для показанного запроса сертификата компьютера. Его не заменяют именем компьютера или пользователя; оно должно соответствовать дальнейшему хранилищу Cert:\LocalMachine\My. |
Где: Windows, PowerShell на доменном компьютере WS01, C:\Clearway-Guide.
Что подставить
| $result — Переменная PowerShell, в которой сохраняется объект результата запроса сертификата. Откуда взять: Выберите имя переменной в своей сессии PowerShell; то же имя нужно использовать в последующих проверках Status и Certificate. | |
| tls — Имя опубликованного шаблона, по которому запрашивается сертификат. Откуда взять: Возьмите точное имя доступного этому компьютеру шаблона из настройки MS-WSTEP и шаблонов центра сертификации; в видео используется tls. | |
| https://wstep.example.test/CEP_Kerberos/service.svc/CEP — Полный HTTPS-адрес службы политики регистрации CEP с Kerberos. Откуда взять: Возьмите DNS-alias сервиса MS-WSTEP и опубликованный URL CEP из результатов его развёртывания; используйте один и тот же адрес при регистрации политики и запросе сертификата. | |
| Cert:\LocalMachine\My — путь к личному хранилищу сертификатов локального компьютера в PowerShell, а не путь к файлу. В показанном машинном сценарии оставьте его без изменения: он соответствует политике с -Context Machine. |
Где: Windows, PowerShell на доменном компьютере WS01, C:\Clearway-Guide.
Показанный результат: Issued.
Что подставить
| $result — Переменная с результатом запроса сертификата. Откуда взять: Укажите то же имя переменной, в которое предыдущая команда Get-Certificate сохранила результат. | |
| Status — фиксированное свойство результата; его не заменяют ожидаемым значением Issued. |
Где: Windows, PowerShell на доменном компьютере WS01, C:\Clearway-Guide.
Что подставить
| $result — Переменная с результатом запроса и выданным сертификатом. Откуда взять: Укажите то же имя переменной, использованное при Get-Certificate в этой сессии. | |
| Certificate и перечисленные свойства Subject, Issuer, SerialNumber, Thumbprint, NotAfter, HasPrivateKey, DnsNameList — фиксированные имена свойств; свои реквизиты вместо них не подставляют. |
О чём ролик
Разбираем ошибку установки по истории развёртываний. На примере временных файлов MS-WSTEP определяем причину Operation not permitted, повторяем очистку с нужными правами и проверяем файлы, службы и результат на клиенте.
Длительность
03:53
| Время | Действие |
|---|---|
| 00:00 | Порядок разбора ошибки. История, сообщение шага, исправление и повторная проверка. |
| 00:20 | Три уровня проверки. Доступ к серверу, пререквизиты и работа сервиса. |
| 00:55 | Поиск запуска в истории. Открытие неуспешного развёртывания MS-WSTEP. |
| 01:07 | Параметры и выполненные шаги. Сопоставление результата и ошибки конкретной команды. |
| 01:32 | Команда и Operation not permitted. Ошибка удаления /tmp/enrollment_services.ldf. |
| 01:57 | Почему удаление не выполнилось. Владелец itc-svc, запуск от cwadmin и права каталога /tmp. |
| 02:17 | Проверка результата развёртывания. Сохранённые файлы и параметры операции. |
| 02:25 | Исправление и повторная проверка. Адресная очистка, поиск файлов и состояние CEP/CES. |
| 03:21 | Возврат к карточке запуска. Сопоставление состояния сервера и истории. |
| 03:33 | Итоговый порядок диагностики. Неуспешный шаг, причина, исправление и клиентская проверка. |
Где: Linux, история развёртывания; команда запускалась от cwadmin.
Для enrollment_services.ldf показано Operation not permitted. Это исходный неуспешный шаг.
Что подставить
| /tmp/enrollment_services.ldf — Точный путь временного файла сведений о службах регистрации из неуспешного шага. Откуда взять: Возьмите путь из команды и сообщения ошибки в истории своего развёртывания; проверьте, что это именно созданный этим запуском временный файл. | |
| /tmp/template_tls_export.ldf — Точный путь временного файла экспорта шаблона; tls в имени относится к демонстрации. Откуда взять: Возьмите имя из команды очистки в истории соответствующего развёртывания и результатов шага экспорта вашего шаблона. | |
| /tmp/add_enrollment_policy.ps1 — Точный путь временного скрипта добавления политики регистрации. Откуда взять: Возьмите путь из команды очистки и результатов своего запуска в истории развёртывания; сохраняйте список конкретных файлов. | |
| Это исходные команды неуспешного шага из истории; подставляются только проверенные пути временных файлов соответствующего запуска. |
Где: Linux, cwadmin@wstep.
Только перечисленные файлы из показанной ошибки.
Что подставить
| /tmp/enrollment_services.ldf — Точный путь временного файла сведений о службах регистрации из неуспешного шага. Откуда взять: Возьмите путь из команды и сообщения ошибки в истории своего развёртывания; проверьте, что это именно созданный этим запуском временный файл. | |
| /tmp/template_tls_export.ldf — Точный путь временного файла экспорта шаблона; tls в имени относится к демонстрации. Откуда взять: Возьмите имя из команды очистки в истории соответствующего развёртывания и результатов шага экспорта вашего шаблона. | |
| /tmp/add_enrollment_policy.ps1 — Точный путь временного скрипта добавления политики регистрации. Откуда взять: Возьмите путь из команды очистки и результатов своего запуска в истории развёртывания; сохраняйте список конкретных файлов. | |
| Подставляйте только конкретные временные файлы из показанного неуспешного шага; не расширяйте список до всего каталога. |
Где: Linux, itc-svc@wstep.
В ролике команда не выводит найденных файлов.
Что подставить
| /tmp — Каталог, где проверяется отсутствие временных файлов. Откуда взять: Возьмите родительский каталог тех файлов, которые проверялись и удалялись на предыдущем шаге. | |
| enrollment_services.ldf — Имя проверяемого файла сведений о службах без пути. Откуда взять: Возьмите имя из полного пути первого временного файла предыдущего шага. | |
| template_tls_export.ldf — Имя проверяемого файла экспорта шаблона без пути. Откуда взять: Возьмите фактическое имя файла экспорта из предыдущего шага; оно может содержать имя вашего шаблона. | |
| add_enrollment_policy.ps1 — Имя проверяемого временного скрипта без пути. Откуда взять: Возьмите имя скрипта из списка временных файлов предыдущего шага. | |
| 1 после -maxdepth ограничивает поиск самим указанным каталогом без обхода вложенных каталогов; это фиксированное ограничение показанной проверки. |
Где: Linux, itc-svc@wstep.
В ролике обе службы active.
Что подставить
| Свои значения подставлять не требуется при такой же установке: wstepCep.service и wstepCesAdapter.service — стандартные имена пользовательских служб CEP/CES. Проверка выполняется в сессии их технологической учётной записи. |
О чём урок
Знакомимся с Контрольной панелью Clearway CA: навигацией, профилем пользователя и основными разделами работы с сертификатами. Разбираем, как выданные права влияют на доступные действия и что проверить перед началом работы с выбранным центром сертификации.
Длительность
06:25
| Время | Действие |
|---|---|
| 00:00 | Знакомство с Контрольной панелью. Понять назначение Контрольной панели и порядок знакомства с её разделами. |
| 00:20 | Как устроен экран. Найти меню, заголовок страницы, панель действий и реестр. |
| 00:47 | Навигация по разделам. Переходить между разделами и пользоваться свёрнутым меню. |
| 01:12 | Профиль и права пользователя. Проверить учётную запись и фактически выданные ей права. |
| 01:41 | Почему интерфейс может отличаться. Сопоставить доступные разделы с ролью и разрешениями пользователя. |
| 02:16 | Сертификаты. Открыть сведения о выданном сертификате и связанные с ним события. |
| 02:47 | Шаблоны и запросы. Найти правила выпуска в шаблонах и результаты рассмотрения запросов. |
| 03:16 | События и списки отзыва. Найти журнал действий и сведения о текущих списках отзыва. |
| 03:53 | Статистика и текущий ЦС. Посмотреть состояние системы и проверить выбранный центр сертификации. |
| 04:20 | Задачи и обслуживание. Найти задачи публикации, резервного копирования и типового обслуживания. |
| 04:54 | Аппаратные токены. Проверить доступность браузерных компонентов для аппаратных носителей. |
| 05:23 | Общие элементы страниц. Освоить фильтры, сортировку, выделение записей и настройку таблицы. |
| 05:55 | Что проверить перед работой. Сверить учётную запись, права и текущий центр сертификации перед действиями. |
О чём урок
Показываем, как найти нужный сертификат в реестре Clearway CA и настроить таблицу для проверки его реквизитов. Используем фильтры по имени, шаблону, статусу и номеру запроса, открываем карточку и сохраняем сертификат в формате PEM или DER.
Длительность
05:02
| Время | Действие |
|---|---|
| 00:00 | Поиск сертификатов и настройка реестра. Определить последовательность: найти запись, проверить сведения, скачать сертификат. |
| 00:22 | Настраиваем столбцы. Выбрать нужные столбцы и применить настройки таблицы. |
| 00:51 | Поиск по имени. Найти сертификаты по значению Subject. |
| 01:19 | Уточняем выборку. Сузить результат фильтрами по шаблону и статусу. |
| 01:45 | Проверяем срок действия. Сопоставить даты начала и окончания действия сертификата. |
| 02:09 | Поиск по номеру запроса. Найти конкретную запись по Request Id. |
| 02:35 | Карточка сертификата. Проверить владельца, статус, сроки действия, параметры ключа и расширения. |
| 03:07 | Скачиваем сертификат. Выбрать формат PEM или DER и сохранить файл сертификата. |
| 03:35 | Почему поиск ничего не нашёл. Обнаружить противоречащие друг другу фильтры и очистить лишние условия. |
| 04:09 | Мои и все сертификаты. Проверить влияние фильтра принадлежности на доступную выборку. |
| 04:35 | От поиска — к результату. Повторить путь от настройки реестра до проверенного файла. |
О чём урок
Готовим запрос на сертификат для video-web.example.test в конструкторе CSR Clearway CA. Выбираем шаблон, задаём CN и SAN, создаём ключ и запрос на сервере Linux командой OpenSSL, затем проверяем подпись и содержимое CSR.
Длительность
04:10
| Время | Действие |
|---|---|
| 00:00 | Подготовка запроса на сертификат. Разделить подготовку запроса, создание ключа и проверку результата. |
| 00:19 | Открываем конструктор и выбираем шаблон. Выбрать хранилище «Файл — Linux/OpenSSL» и шаблон tls. |
| 00:44 | Проверяем параметры ключа. Проверить RSA, размер ключа 2048 бит и SHA-256. |
| 01:06 | Указываем имя учебного сервиса. Задать имя video-web.example.test в Common Name. |
| 01:32 | Задаём имена файлов. Указать имена video-web.csr и video-web.key. |
| 01:58 | Добавляем имя в SAN. Добавить DNS-имя сервиса в Subject Alternative Name. |
| 02:26 | Копируем готовую команду. Скопировать сформированную OpenSSL-команду для выбранных параметров. |
| 02:47 | Создаём ключ и запрос на сервере. Создать закрытый ключ и CSR на сервере и проверить права файлов. |
| 03:25 | Проверяем готовый CSR. Проверить собственную подпись CSR, Subject, SAN и запрошенные расширения. |
| 03:49 | Запрос готов к выпуску сертификата. Подготовить CSR к загрузке в центр сертификации, сохранив ключ на сервере. |
Где: Терминал Linux, каталог учебного запроса на сервере ca.
Что подставить
| Свои значения подставлять не требуется: umask 077 — фиксированная команда из примера, ограничивающая доступ к вновь создаваемым файлам владельцем. |
Где: Терминал Linux; команда скопирована из конструктора CSR.
-keyout и -out задают файлы ключа и запроса; -nodes оставляет ключ без парольного шифрования; -sha256 выбирает хеш подписи CSR; -addext добавляет расширения.
Что подставить
| rsa:2048 — Алгоритм RSA и длина создаваемого ключа 2048 бит. Откуда взять: Выберите алгоритм и длину по требованиям целевой системы и шаблона сертификата; в примере используется RSA 2048. При другой длине RSA изменяется число после rsa:. | |
| video-web.key — Имя выходного файла закрытого ключа. Откуда взять: Выберите имя и каталог для нового ключа; затем используйте тот же путь при проверке и настройке приложения. Закрытый ключ остаётся у владельца и не включается в CSR. | |
| video-web.csr — Имя выходного файла запроса на сертификат. Откуда взять: Выберите имя файла CSR; этот файл проверяется следующими командами и затем загружается в Контрольную панель. | |
| /CN=video-web.example.test — Subject запроса в синтаксисе OpenSSL: CN содержит имя сервиса. Откуда взять: Укажите имя своего сервиса в соответствии с требованиями шаблона сертификата; в учебном примере это video-web.example.test. Сохраните синтаксис /CN= при замене значения. | |
| DNS:video-web.example.test — DNS-имя сервиса в расширении Subject Alternative Name (SAN). Откуда взять: Возьмите фактическое DNS-имя, по которому клиенты подключаются к сервису. Укажите его после DNS:; список имён должен соответствовать назначению сертификата и разрешениям шаблона. |
Где: Тот же каталог в терминале Linux.
В примере у обоих файлов показаны права -rw-------.
Что подставить
| video-web.key — Файл созданного закрытого ключа, права которого проверяются. Откуда взять: Используйте имя, заданное после -keyout при создании ключа и CSR на 02:50. | |
| video-web.csr — Входной файл запроса на сертификат (CSR). Откуда взять: Возьмите файл, созданный командой openssl req в этом ролике на 02:50; если выбрали другое имя, используйте его во всех следующих командах. |
Где: Тот же каталог в терминале Linux.
В ролике получен результат Certificate request self-signature verify OK.
Что подставить
| video-web.csr — Входной файл запроса на сертификат (CSR). Откуда взять: Возьмите файл, созданный командой openssl req в этом ролике на 02:50; если выбрали другое имя, используйте его во всех следующих командах. |
Где: Тот же каталог в терминале Linux.
Что подставить
| video-web.csr — Входной файл запроса на сертификат (CSR). Откуда взять: Возьмите файл, созданный командой openssl req в этом ролике на 02:50; если выбрали другое имя, используйте его во всех следующих командах. |
О чём урок
Выпускаем сертификат по CSR, подготовленному в предыдущем ролике. Загружаем запрос в Clearway CA, сравниваем его параметры с шаблоном, проверяем выданный сертификат в реестре и сохраняем файл PEM.
Длительность
03:46
| Время | Действие |
|---|---|
| 00:00 | От запроса к сертификату. Определить исходный CSR и требуемый результат выпуска. |
| 00:20 | Открываем запрос сертификата. Открыть форму запроса сертификата и выбрать шаблон tls. |
| 00:43 | Загружаем готовый CSR. Загрузить файл video-web.csr. |
| 01:07 | Просматриваем структуру. Сравнить ключ, Subject, SAN и расширения запроса с параметрами шаблона. |
| 01:35 | Проверяем и отправляем. Проверить выбранный шаблон и отправить запрос на выпуск. |
| 02:02 | Находим выданный сертификат. Найти новую запись по имени video-web.example.test. |
| 02:25 | Проверяем карточку. Проверить статус, срок действия, ключ, SAN и назначение сертификата. |
| 02:51 | Сохраняем файл. Скачать выпущенный сертификат в формате PEM. |
| 03:19 | Сертификат получен. Убедиться, что сертификат получен, а закрытый ключ сохранён отдельно на сервере. |
О чём урок
Разбираем выпуск сертификатов с предварительным согласованием в Clearway CA. Отправляем запрос по учебному шаблону, проверяем заявку со статусом Pending, одобряем её, а повторную заявку отклоняем с сохранением причины.
Длительность
04:26
| Время | Действие |
|---|---|
| 00:00 | Согласование запросов на сертификаты. Проследить путь от подачи заявки до принятого решения. |
| 00:28 | Проверяем условие согласования и права. Проверить признак «Создавать запрос на выпуск» и права отправки и согласования. |
| 00:58 | Отправляем заявку на рассмотрение. Передать CSR по шаблону video05-approval на рассмотрение. |
| 01:29 | Находим ожидающий запрос. Открыть созданную заявку в разделе «Запросы» и проверить Pending. |
| 01:54 | Проверяем заявку перед решением. Сверить заявителя, Subject, SAN, шаблон и параметры ключа. |
| 02:18 | Одобряем и проверяем сертификат. Одобрить заявку и открыть связанный выпущенный сертификат. |
| 02:46 | Рассматриваем повторный запрос. Проверить повторную заявку до принятия решения. |
| 03:10 | Отклоняем с понятной причиной. Отклонить повторный запрос и указать понятную причину. |
| 03:35 | Сравниваем итоговые состояния. Сравнить Satisfied и Rejected и проверить сохранённые результаты. |
| 04:02 | Решения приняты и проверены. Убедиться, что одобренная заявка связана с сертификатом, а отклонённая содержит причину. |
О чём урок
Выпускаем два сертификата одним пакетным запросом Clearway CA. Готовим текстовый список имён, выбираем общий шаблон и пароль, затем проверяем полученный архив с контейнерами PFX и обе записи в реестре.
Длительность
03:59
| Время | Действие |
|---|---|
| 00:00 | Два сертификата одним запросом. Определить состав пакета и ожидаемые два сертификата. |
| 00:22 | Готовим список имён. В GNU nano подготовить batch06-subjects.txt: по одному имени на строке. |
| 01:10 | Проверяем и сохраняем файл. Убрать лишние атрибуты учебного примера, проверить две строки и сохранить файл. |
| 01:35 | Открываем пакетный запрос. Открыть форму пакетного запроса сертификатов. |
| 01:59 | Заполняем форму. Выбрать шаблон tls, задать пароль и загрузить список. |
| 02:21 | Отправляем пакет. Отправить пакетный запрос и получить файл результата. |
| 02:35 | Проверяем архив. Проверить, что ZIP содержит два контейнера PFX с ожидаемыми именами. |
| 03:01 | Проверяем обе карточки. Открыть обе записи и сопоставить имена, статусы, сроки и параметры ключей. |
| 03:33 | Пакет проверен. Сопоставить исходные две строки, два контейнера и две карточки сертификатов. |
Где: Терминал Linux, каталог ~/Downloads.
-l показывает содержимое ZIP без извлечения. Фактическое имя скачанного архива зависит от времени выпуска.
Что подставить
| certificates_2026_10_11_20_40.zip — Имя скачанного ZIP-архива с результатами пакетного выпуска сертификатов. Откуда взять: Возьмите фактическое имя архива, скачанного в предыдущем шаге пакетного выпуска, или укажите полный путь к нему. Дата и время в имени относятся к примеру, их не нужно переносить в своё имя вручную. |
О чём урок
Создаём собственный серверный шаблон сертификата в Clearway CA: задаём срок действия, параметры ключа и назначение. Показываем сохранение новой версии, создание отдельной копии, экспорт выбранных шаблонов и порядок импорта из JSON.
Длительность
04:49
| Время | Действие |
|---|---|
| 00:00 | Свой учебный шаблон. Определить параметры отдельного учебного серверного шаблона. |
| 00:22 | Задаём имя и описание. Создать video07-server и заполнить описание. |
| 00:46 | Срок и параметры ключа. Установить максимум 30 дней, тип RSA и минимальный размер 2048 бит. |
| 01:11 | Выбираем назначение. Настроить Key Usage и Extended Key Usage для аутентификации сервера. |
| 01:35 | Проверяем и сохраняем. Сверить параметры формы и сохранить новый шаблон. |
| 02:03 | Проверяем сохранённый шаблон. Открыть карточку и проверить сохранённую первую версию. |
| 02:26 | Сохраняем новую версию. Изменить описание, сохранить и проверить увеличение номера версии. |
| 02:50 | Создаём отдельную копию. Создать video07-server-copy как отдельный шаблон. |
| 03:13 | Экспортируем два шаблона. Отобрать два учебных шаблона фильтром и выгрузить их в JSON. |
| 03:41 | Импортируем шаблоны из файла. Разобрать загрузку JSON и поведение импорта при новом и существующем имени. |
| 04:24 | Шаблон, копия и экспорт готовы. Сверить исходный шаблон, отдельную копию и файл экспорта. |
О чём урок
Настраиваем права доступа и ограничения запроса в шаблоне Clearway CA. Разбираем отдельные разрешения на просмотр, изменение и выпуск, задаём обязательную организацию и допустимый DNS-домен, затем сравниваем отклонённый и успешно выпущенный запросы.
Длительность
04:27
| Время | Действие |
|---|---|
| 00:00 | Ограничения и права шаблона. Разделить контроль доступа к шаблону и проверку параметров сертификата. |
| 00:23 | Открываем учебную копию. Открыть отдельный учебный шаблон video08-policy. |
| 00:41 | Три независимых разрешения. Найти независимые разрешения на просмотр, изменение и выпуск. |
| 01:04 | Роли в claim токена. Понять, как назначенная роль поступает в токен и сопоставляется с разрешением шаблона. |
| 01:38 | Ограничиваем право выпуска. Указать роль rleMiniCATempl-w в разрешении на выпуск учебного шаблона. |
| 02:02 | Точное значение организации. Сделать Organization обязательным и задать точное значение Clearway Lab. |
| 02:24 | Допустимые DNS-имена. Сделать DNS SAN обязательным и ограничить имена маской *.example.test. |
| 02:47 | Сохраняем весь шаблон. Сохранить карточку шаблона после изменения правил и разрешений. |
| 03:11 | Проверяем неправильный запрос. Отправить CSR с неподходящей организацией и проверить причину отказа. |
| 03:37 | Проверяем подходящий запрос. Отправить подходящий CSR и проверить выпущенную запись. |
| 04:04 | Права и правила проверены. Подтвердить, что действуют и правила доступа, и ограничения Subject/SAN. |
О чём урок
Показываем приостановку и восстановление сертификатов в Clearway CA на одиночной записи и группе из двух записей. Проверяем выбранные сертификаты, используем причину CertificateHold и контролируем итоговый статус после каждой операции.
Длительность
03:54
| Время | Действие |
|---|---|
| 00:00 | Отзыв и восстановление сертификатов. Определить безопасный учебный сценарий приостановки и восстановления. |
| 00:25 | Проверяем выбранный сертификат. Сверить имя, Request Id, Serial Number и исходный статус сертификата. |
| 00:48 | Выбираем причину отзыва. Выбрать CertificateHold как причину временной приостановки. |
| 01:14 | Проверяем приостановку. Проверить статус «Отозван» и сохранённую причину CertificateHold. |
| 01:42 | Восстанавливаем одну запись. Выделить запись в реестре и подтвердить её восстановление. |
| 02:09 | Выбираем две учебные записи. Проверить состав группы из двух учебных сертификатов. |
| 02:35 | Выполняем групповой отзыв. Приостановить оба сертификата с причиной CertificateHold. |
| 02:58 | Восстанавливаем две записи. Восстановить обе записи и проверить количество обработанных сертификатов. |
| 03:28 | Причина определяет возможность восстановления. Закрепить условие: восстановление доступно только после CertificateHold. |
О чём урок
Настраиваем почтовую подписку на события сертификата в Clearway CA: проверяем адрес, добавляем получателя и выбираем уведомления о выпуске, отзыве и истечении срока. Создаём учебное событие отзыва и проверяем фактически доставленное письмо в Mailpit.
Длительность
03:24
| Время | Действие |
|---|---|
| 00:00 | Уведомления по электронной почте. Разделить настройку подписки и проверку доставки уведомления. |
| 00:24 | Открываем подписки сертификата. Открыть вкладку «Подписки» в карточке сертификата. |
| 00:45 | Проверяем формат адреса. Проверить, что неверно записанный адрес отклоняется. |
| 01:04 | Добавляем получателя. Добавить viewer@notify.example.test в список получателей. |
| 01:26 | Выбираем события. Отметить события выпуска, отзыва и истечения срока действия. |
| 01:52 | Сохраняем и повторно проверяем. Сохранить параметры и повторно проверить адрес и флажки подписки. |
| 02:09 | Создаём учебное событие. Приостановить учебный сертификат с причиной CertificateHold для проверки уведомления. |
| 02:34 | Проверяем поступившее письмо. В Mailpit найти письмо и сверить получателя, имя и серийный номер сертификата. |
| 02:59 | Подписка и доставка проверяются отдельно. Убедиться отдельно в сохранении подписки и поступлении письма. |
О чём урок
Работаем с полным списком отзыва CRL и разностным Delta CRL в Clearway CA. Просматриваем сведения, обновляем списки, запускаем задачи публикации и проверяем скачанные по HTTP файлы с помощью OpenSSL.
Длительность
04:27
| Время | Действие |
|---|---|
| 00:00 | Работа с CRL и Delta CRL. Разделить просмотр, формирование и публикацию списков отзыва. |
| 00:28 | Читаем карточки списков. Проверить номера, время обновления и сведения об отозванных сертификатах. |
| 00:54 | Скачиваем текущий CRL. Сохранить текущий полный список через меню «Действия». |
| 01:16 | Выбираем режим обновления. Сравнить режим «Новый CRL» с обновлением только Delta CRL. |
| 01:44 | Проверяем новый полный список. Сверить изменившиеся номера и время формирования списков. |
| 02:07 | Обновляем только Delta CRL. Сформировать новый Delta CRL и проверить, что полный список не изменился. |
| 02:44 | Проверяем задачи публикации. Проверить задачи base и delta, расписания и пути публикации. |
| 03:13 | Запускаем обе задачи. Запустить вне расписания задачи публикации полного и разностного списков. |
| 03:38 | Проверяем опубликованные файлы. Скачать оба опубликованных файла, проверить подписи, номера и даты. |
| 04:03 | Обновление и публикация имеют разные проверки. Сопоставить состояние в центре сертификации с доступными по HTTP файлами. |
Где: Терминал Linux, рабочий каталог video-guide-11.
-f сообщает об ошибках HTTP; -sS убирает индикатор прогресса, сохраняя сообщения об ошибках; -o задаёт файл результата.
Что подставить
| http://ca.example.test/cdp/RootCA.crl — Полный URL опубликованного полного CRL; домен и имя файла в примере принадлежат учебному центру. Откуда взять: Возьмите адрес CRL Distribution Points (CDP) из проверяемого сертификата или согласованных настроек публикации своего центра сертификации; используйте весь адрес со своим доменом и путём. | |
| published-full.crl — Имя выходного файла для скачанного полного CRL. Откуда взять: Выберите локальное имя и каталог; затем подставьте этот же путь в следующую команду openssl crl. |
Где: Тот же каталог; рядом находится доверенный сертификат issuer.pem.
-inform DER задаёт двоичную кодировку; -verify проверяет подпись; 2>&1 объединяет потоки вывода, tee показывает результат и записывает его в файл.
Что подставить
| published-full.crl — Локальный входной файл полного списка отзыва. Откуда взять: Используйте имя файла, указанное после -o в предыдущей команде скачивания полного CRL на 03:38. | |
| issuer.pem — PEM-файл сертификата центра сертификации, подписавшего проверяемый CRL. Откуда взять: Получите сертификат подписавшего центра у администратора или из согласованной точки публикации и проверьте его подлинность; укажите путь к подготовленному файлу. Это не сертификат конечного пользователя. | |
| full-check.txt — Выходной текстовый файл с результатом проверки полного CRL. Откуда взять: Выберите имя файла журнала и каталог, в который можно записать результат. tee показывает вывод в терминале и сохраняет его под этим именем. |
Где: Терминал Linux, рабочий каталог video-guide-11.
Что подставить
| http://ca.example.test/cdp/RootCA+.crl — Полный URL опубликованного Delta CRL; знак + входит в имя файла учебного примера. Откуда взять: Возьмите адрес разностного списка отзыва из настроек публикации центра или соответствующего расширения Freshest CRL сертификата/полного CRL. Не составляйте свой URL простым добавлением + к адресу полного CRL. | |
| published-delta.crl — Имя выходного файла для скачанного Delta CRL. Откуда взять: Выберите локальное имя и каталог; используйте тот же путь в следующей команде проверки разностного списка. |
Где: Тот же каталог; рядом находится доверенный сертификат issuer.pem.
В ролике для обоих списков получен результат verify OK.
Что подставить
| published-delta.crl — Локальный входной файл разностного списка отзыва. Откуда взять: Используйте имя файла, указанное после -o в команде скачивания Delta CRL на 03:50. | |
| issuer.pem — PEM-файл сертификата центра сертификации, подписавшего проверяемый CRL. Откуда взять: Получите сертификат подписавшего центра у администратора или из согласованной точки публикации и проверьте его подлинность; укажите путь к подготовленному файлу. Это не сертификат конечного пользователя. | |
| delta-check.txt — Выходной текстовый файл с результатом проверки Delta CRL. Откуда взять: Выберите отдельное имя журнала для разностного списка, чтобы сохранить результат этой проверки. |
О чём урок
Проверяем статус сертификата через OCSP с помощью OpenSSL. На одном учебном сертификате сравниваем ответы good, revoked с причиной certificateHold и good после восстановления, каждый раз проверяя подпись ответа и его время.
Длительность
03:38
| Время | Действие |
|---|---|
| 00:00 | Проверка статуса через OCSP. Определить три проверяемых состояния и необходимые файлы сертификатов. |
| 00:23 | Проверяем сертификат и адрес. Сверить Subject, Issuer, серийный номер и OCSP-адрес проверяемого сертификата. |
| 00:45 | Подготавливаем сертификат ЦС. Проверить сертификат центра сертификации, используемый для запроса и проверки подписи. |
| 01:09 | Отправляем запрос OCSP. Отправить OCSP-запрос и сохранить вывод первой проверки. |
| 01:38 | Читаем ответ действующего сертификата. Проверить Response verify OK, good, This Update и Next Update. |
| 02:03 | Сравниваем ответ после приостановки. Повторить проверку после приостановки и прочитать revoked и certificateHold. |
| 02:25 | Восстанавливаем учебный сертификат. Восстановить выбранный сертификат в реестре Контрольной панели. |
| 02:49 | Проверяем ответ после восстановления. Повторить OCSP-запрос и убедиться в возврате статуса good. |
| 03:14 | Проверяйте подпись, статус и время. Проверять подпись, статус и актуальность ответа как отдельные условия. |
Где: Терминал Linux, рабочий каталог video-guide-12.
Что подставить
| cert.pem — Входной PEM-файл сертификата, статус которого проверяется. Откуда взять: Сохраните проверяемый сертификат из Контрольной панели или возьмите его из приложения, для которого он выпущен; укажите своё имя файла. Один и тот же сертификат используется до отзыва, после отзыва и после возобновления. |
Где: Тот же каталог в терминале Linux.
В примере выводится http://ca.example.test:8888/ocsp.
Что подставить
| cert.pem — Входной PEM-файл сертификата, статус которого проверяется. Откуда взять: Сохраните проверяемый сертификат из Контрольной панели или возьмите его из приложения, для которого он выпущен; укажите своё имя файла. Один и тот же сертификат используется до отзыва, после отзыва и после возобновления. |
Где: Тот же каталог в терминале Linux.
В показанном сертификате оба поля относятся к RootCA.
Что подставить
| issuer.pem — PEM-файл сертификата непосредственного издателя проверяемого сертификата. Откуда взять: Получите сертификат центра, который выпустил cert.pem, у администратора или из согласованной точки публикации и проверьте его подлинность. В ролике это корневой центр RootCA. |
Где: Терминал Linux с файлами cert.pem и issuer.pem.
-issuer задаёт сертификат выдавшего центра сертификации; -cert — проверяемый сертификат; -url — адрес ответчика; -CAfile — доверенный сертификат; tee сохраняет вывод.
Что подставить
| issuer.pem — В примере один файл используется дважды: после -issuer — сертификат издателя cert.pem, после -CAfile — доверенный сертификат для проверки подписи OCSP-ответа. Откуда взять: Возьмите проверенный сертификат RootCA из подготовительного шага на 00:45. Если ваш сертификат выдан промежуточным центром, для -issuer нужен его сертификат, а для -CAfile — отдельно подготовленный доверенный корневой сертификат или файл цепочки; эти два пути могут различаться. | |
| cert.pem — Входной PEM-файл сертификата, статус которого проверяется. Откуда взять: Сохраните проверяемый сертификат из Контрольной панели или возьмите его из приложения, для которого он выпущен; укажите своё имя файла. Один и тот же сертификат используется до отзыва, после отзыва и после возобновления. | |
| http://ca.example.test:8888/ocsp — Полный адрес OCSP-ответчика: имя сервера ca.example.test, порт 8888 и путь /ocsp относятся к учебному стенду. Откуда взять: Возьмите адрес из результата openssl x509 -ocsp_uri на 00:32 или из согласованной конфигурации вашей инфраструктуры; подставляйте весь URL вместе с его схемой, портом и путём. | |
| response-good.txt — Выходной файл с первоначальным OCSP-ответом и результатом его проверки. Откуда взять: Выберите имя журнала для проверки сертификата до отзыва; файл создаёт tee в текущем каталоге либо по указанному пути. |
Где: Тот же каталог в терминале Linux.
Показаны Response verify OK, revoked, Reason: certificateHold и время отзыва.
Что подставить
| issuer.pem — В примере один файл используется дважды: после -issuer — сертификат издателя cert.pem, после -CAfile — доверенный сертификат для проверки подписи OCSP-ответа. Откуда взять: Возьмите проверенный сертификат RootCA из подготовительного шага на 00:45. Если ваш сертификат выдан промежуточным центром, для -issuer нужен его сертификат, а для -CAfile — отдельно подготовленный доверенный корневой сертификат или файл цепочки; эти два пути могут различаться. | |
| cert.pem — Входной PEM-файл сертификата, статус которого проверяется. Откуда взять: Сохраните проверяемый сертификат из Контрольной панели или возьмите его из приложения, для которого он выпущен; укажите своё имя файла. Один и тот же сертификат используется до отзыва, после отзыва и после возобновления. | |
| http://ca.example.test:8888/ocsp — Полный адрес OCSP-ответчика: имя сервера ca.example.test, порт 8888 и путь /ocsp относятся к учебному стенду. Откуда взять: Возьмите адрес из результата openssl x509 -ocsp_uri на 00:32 или из согласованной конфигурации вашей инфраструктуры; подставляйте весь URL вместе с его схемой, портом и путём. | |
| response-revoked.txt — Выходной файл с OCSP-ответом после отзыва сертификата. Откуда взять: Выберите отдельное имя журнала для проверки отозванного сертификата, чтобы сравнить его с первоначальным ответом. |
Где: Тот же каталог в терминале Linux.
Проверяются подпись ответа, статус и поля This Update / Next Update.
Что подставить
| issuer.pem — В примере один файл используется дважды: после -issuer — сертификат издателя cert.pem, после -CAfile — доверенный сертификат для проверки подписи OCSP-ответа. Откуда взять: Возьмите проверенный сертификат RootCA из подготовительного шага на 00:45. Если ваш сертификат выдан промежуточным центром, для -issuer нужен его сертификат, а для -CAfile — отдельно подготовленный доверенный корневой сертификат или файл цепочки; эти два пути могут различаться. | |
| cert.pem — Входной PEM-файл сертификата, статус которого проверяется. Откуда взять: Сохраните проверяемый сертификат из Контрольной панели или возьмите его из приложения, для которого он выпущен; укажите своё имя файла. Один и тот же сертификат используется до отзыва, после отзыва и после возобновления. | |
| http://ca.example.test:8888/ocsp — Полный адрес OCSP-ответчика: имя сервера ca.example.test, порт 8888 и путь /ocsp относятся к учебному стенду. Откуда взять: Возьмите адрес из результата openssl x509 -ocsp_uri на 00:32 или из согласованной конфигурации вашей инфраструктуры; подставляйте весь URL вместе с его схемой, портом и путём. | |
| response-restored.txt — Выходной файл с OCSP-ответом после возобновления действия сертификата. Откуда взять: Выберите отдельное имя журнала для заключительной проверки и сравнения со статусами до отзыва и после него. |
О чём урок
Создаём на физическом Рутокене отдельную учебную ключевую пару и запрос на сертификат, выпускаем сертификат через Clearway CA, добавляем его на тот же носитель и сверяем результат. Существующие ключи и сертификаты не изменяются.
Длительность
03:45
| Время | Действие |
|---|---|
| 00:00 | Работа с аппаратным токеном |
| 00:18 | Готовность рабочего места |
| 00:39 | Исходное содержимое токена |
| 00:59 | Конструктор и шаблон |
| 01:21 | Метка ключа и данные владельца |
| 01:44 | Создание ключа и запроса |
| 02:08 | Сохранение запроса |
| 02:25 | Выпуск и запись сертификата |
| 02:48 | Проверка результата |
| 03:16 | Итог |
О чём урок
Показываем, как работать с несколькими центрами сертификации в одной Контрольной панели Clearway CA и проверять выбранное подключение перед операцией. Переключаемся между центрами, сравниваем их реестры и сверяем издателя сертификата и состав скачанной цепочки с выбранным контекстом.
Длительность
02:45
| Время | Действие |
|---|---|
| 00:00 | Один интерфейс, несколько ЦС. Разбираем работу одной Контрольной панели с несколькими заранее настроенными подключениями к центрам сертификации. |
| 00:18 | Находим текущий ЦС. Открываем «Настройки → Конфигурация» и определяем активное подключение, его адрес и имя центра сертификации. |
| 00:34 | Проверяем состояние. Открываем сведения о выбранном центре, сверяем его версию, идентификатор ключа и показанное состояние. |
| 00:57 | Смотрим первый реестр. Открываем реестр первого центра и карточку сертификата, чтобы зафиксировать исходный контекст. |
| 01:18 | Переключаем центр. В настройках выбираем подключение training-issuing и возвращаемся к данным выдающего центра сертификации. |
| 01:38 | Проверяем выбранный контекст. Сверяем реестр второго центра, скачиваем сертификат functional15.example.test и читаем его subject, issuer и серийный номер через OpenSSL. |
| 02:04 | Скачиваем цепочку. Скачиваем цепочку сертификатов в настройках и через OpenSSL проверяем, что она содержит учебный корневой и выдающий центры. |
| 02:26 | Контекст проверен. Подводим итог проверки: название подключения сопоставлено с центром, реестром и издателем сертификата; перед следующей операцией нужно проверить активный контекст. |
Где: Терминал Linux, каталог video-guide-14-terminal с файлами, скачанными из Контрольной панели.
Что подставить
| functional15.example.test.cer — Входной файл сертификата, для которого читаются субъект, издатель и серийный номер. Откуда взять: Скачать нужный сертификат из реестра выбранного центра в предыдущем шаге и указать его фактическое имя или путь. |
Где: Терминал Linux, каталог video-guide-14-terminal с файлами, скачанными из Контрольной панели.
Что подставить
| minica-chain.cer — Входной файл цепочки сертификатов выбранного центра. Откуда взять: Скачать цепочку через настройки активного подключения в предыдущем шаге; взять фактическое имя файла из каталога загрузок. |
О чём урок
Получаем сертификат через SCEP в Clearway CA с помощью certmonger: проверяем доверие, добавляем подключение и запрашиваем одноразовый пароль. После выпуска проверяем состояние запроса, поля сертификата и его цепочку, затем сверяем результат с записью в реестре центра сертификации.
Длительность
03:09
| Время | Действие |
|---|---|
| 00:00 | Запрос через SCEP. Рассматриваем выпуск учебного сертификата через SCEP и признаки результата, которые затем проверим на клиенте и в центре сертификации. |
| 00:13 | Проверяем исходные данные. Переходим в рабочий каталог и проверяем субъект и SHA-256 отпечаток подготовленного корневого сертификата. |
| 00:32 | Готовим каталог. Создаём каталог private с правами 700 для закрытого ключа клиента. |
| 00:47 | Получаем сертификаты адаптера. Запрашиваем GetCACert по HTTPS с проверкой доверия и просматриваем сертификаты в полученном контейнере PKCS#7. |
| 01:08 | Добавляем подключение. Регистрируем SCEP-подключение Clearway-Functional15 в certmonger с URL адаптера, сертификатами корневого и выдающего центров и RA; проверяем созданную запись. |
| 01:25 | Получаем одноразовый пароль. Вводим токен OpenID без отображения на экране, получаем challenge-password в защищённый файл и удаляем токен из переменной оболочки. |
| 01:49 | Отправляем запрос. Отправляем запрос certmonger с RSA-ключом 2048 бит, CN и DNS SAN functional15.example.test; задаём пути результата, файл одноразового пароля и ожидание ответа. |
| 02:06 | Проверяем результат на клиенте. Проверяем состояние MONITORING без stuck, читаем subject, issuer, serial, сроки и SAN, затем проверяем цепочку сертификата. |
| 02:28 | Сверяем реестр. В Контрольной панели находим выпущенный сертификат и сверяем его субъект, издателя, серийный номер и SAN с результатом на клиенте. |
| 02:50 | Сертификат проверен. Фиксируем успешный выпуск и проверки. В показанном запросе автоматическое продление отключено; повторный запрос требует нового одноразового пароля. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| /root/functional15 — Рабочий каталог SCEP-клиента с подготовленными сертификатами доверия и результатами запроса. Откуда взять: Выбрать или создать каталог на сервере, которому нужен сертификат; предварительно сохранить в него подготовленные сертификаты и далее согласовать с ним полные пути в certmonger. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| private — Выходной подкаталог для закрытого ключа, создаваемый внутри текущего рабочего каталога. Откуда взять: Выбрать имя каталога для своего ключа; тот же путь использовать в параметре -k будущего getcert request. | |
| 700 — показанный режим доступа только владельцу; это не имя каталога и для повторения сценария его менять не требуется. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. | |
| https://scep.example.test/api/scep/v1/scep — Базовый HTTPS-адрес службы SCEP, включая домен и маршрут адаптера. Откуда взять: Возьмите внешний базовый URL из конфигурации своего SCEP-адаптера или у администратора, включая его фактический маршрут. В запросе GetCACert к нему добавляется буквальный суффикс ?operation=GetCACert, в запросе одноразового пароля — /challenge-password; названия этих операций своими значениями не заменяются. | |
| scep-ca.p7b — Выходной файл ответа GetCACert с сертификатами адаптера и центра. Откуда взять: Выбрать имя сохраняемого контейнера в рабочем каталоге; это же имя передать следующей команде openssl pkcs7. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| scep-ca.p7b — Входной контейнер сертификатов SCEP в формате DER PKCS#7. Откуда взять: Взять файл, сохранённый предыдущим curl GetCACert через -o, с фактическим выбранным именем. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| Clearway-Functional15 — Локальное имя SCEP-подключения в certmonger после -c. Откуда взять: При добавлении подключения выбрать уникальное удобное имя; в последующих командах использовать имя, зарегистрированное командой getcert add-scep-ca. | |
| https://scep.example.test/api/scep/v1/scep — Базовый HTTPS-адрес службы SCEP, включая домен и маршрут адаптера. Откуда взять: Возьмите внешний базовый URL из конфигурации своего SCEP-адаптера или у администратора, включая его фактический маршрут. В запросе GetCACert к нему добавляется буквальный суффикс ?operation=GetCACert, в запросе одноразового пароля — /challenge-password; названия этих операций своими значениями не заменяются. | |
| /root/functional15/root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. | |
| /root/functional15/issuing-ca.crt — Полный путь к входному сертификату выдающего центра для подключения certmonger. Откуда взять: Взять сертификат выдающего центра из подготовленной цепочки или ответа GetCACert и сохранить отдельным файлом; если выпускает сам корневой центр, по руководству здесь указывают его сертификат. | |
| /root/functional15/scep-ra.pem — Полный путь к входному сертификату адаптера SCEP (RA). Откуда взять: Выделить сертификат RA из ответа GetCACert либо получить подготовленный файл у администратора адаптера; сохранить PEM-файл и указать полный путь. | |
| Три файла сертификатов должны быть подготовлены до регистрации подключения. Показанная перед этим команда openssl pkcs7 с -noout выводит сведения о сертификатах и не сохраняет отдельные PEM-файлы; пути -R, -N и -r указывают на уже подготовленные файлы. Их полные пути нужны службе certmonger и при последующих обращениях. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| Clearway-Functional15 — Локальное имя SCEP-подключения в certmonger после -c. Откуда взять: При добавлении подключения выбрать уникальное удобное имя; в последующих командах использовать имя, зарегистрированное командой getcert add-scep-ca. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Значение токена в видео не раскрывается; в команду его подставлять не требуется.
Что подставить
| TOKEN — Имя переменной оболочки, в которую read скрыто считывает токен доступа OpenID; сам токен вводится после приглашения, а не вместо имени TOKEN. Откуда взять: Получить свежий токен доступа у службы OpenID по порядку, установленному администратором своей инсталляции. Имя переменной можно оставить TOKEN; при смене согласовать его с последующими $TOKEN и unset. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| $TOKEN — Ссылка на переменную со свежим токеном доступа OpenID для заголовка Authorization. Откуда взять: Заполнить переменную предыдущей командой read; использовать то же имя переменной. Не вставлять текст токена прямо в строку команды. | |
| root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. | |
| https://scep.example.test/api/scep/v1/scep — Базовый HTTPS-адрес службы SCEP, включая домен и маршрут адаптера. Откуда взять: Возьмите внешний базовый URL из конфигурации своего SCEP-адаптера или у администратора, включая его фактический маршрут. В запросе GetCACert к нему добавляется буквальный суффикс ?operation=GetCACert, в запросе одноразового пароля — /challenge-password; названия этих операций своими значениями не заменяются. | |
| challenge.txt — Выходной файл с полученным одноразовым паролем SCEP. Откуда взять: Выбрать имя файла на том же клиенте; позже указать его полный путь после -l в getcert request. При повторном запросе получить новый пароль. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| TOKEN — Имя переменной, из которой удаляется ранее введённый токен. Откуда взять: Использовать то же имя, что было задано в read для получения токена; если оставили пример без переименования, оставить TOKEN. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
У команды request параметр -R отключает автоматическое продление; -l указывает файл одноразового пароля.
Что подставить
| Clearway-Functional15 — Локальное имя SCEP-подключения в certmonger после -c. Откуда взять: При добавлении подключения выбрать уникальное удобное имя; в последующих командах использовать имя, зарегистрированное командой getcert add-scep-ca. | |
| functional15 — Имя задачи certmonger после -I; по нему запрос затем проверяется и повторяется. Откуда взять: Выбрать уникальное имя своей задачи при первом запросе; сохранить его для getcert list -i и других обращений к этому запросу. | |
| RSA — Выбранный алгоритм создаваемого ключа после -G. Откуда взять: Взять допустимый тип ключа из настроек шаблона, используемого своим SCEP-адаптером, и требований клиента; пример использует RSA. | |
| 2048 — Размер RSA-ключа в битах после -g. Откуда взять: Выбрать размер, удовлетворяющий требованиям шаблона своего центра и поддерживаемый клиентом; 2048 — значение учебного примера. | |
| /root/functional15/private/functional15.key — Выходной файл создаваемого закрытого ключа; certmonger использует этот путь и после первого запроса. Откуда взять: Выбрать полное имя файла в заранее созданном защищённом каталоге private; проверить соответствие выбранному рабочему каталогу и не подставлять файл чужого ключа. | |
| /root/functional15/functional15.crt — Выходной файл получаемого сертификата. Откуда взять: Выбрать полный путь к результату на клиенте; затем использовать этот же файл в проверках OpenSSL и настройках потребителя сертификата. | |
| functional15.example.test — Имя владельца в CN= после -N и DNS-имя SAN после -D; в примере оба значения совпадают. Откуда взять: Взять сервисное DNS-имя клиента, для которого выпускается сертификат, из его DNS/конфигурации сервиса; сверить допустимые имена с шаблоном. При различающихся CN и SAN заполнить каждую позицию по требованиям своего сертификата. | |
| /root/functional15/challenge.txt — Входной файл одноразового пароля после -l. Откуда взять: Указать полный путь к challenge.txt, полученному на предыдущем шаге от SCEP-адаптера для этого выпуска. | |
| 90 — Максимальное время ожидания результата в секундах после --wait-timeout. Откуда взять: Выбрать допустимое время ожидания для своей операции; по руководству истечение этого интервала не отменяет задачу certmonger. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| functional15 — Имя проверяемой задачи certmonger после -i. Откуда взять: Взять ровно то имя, которое задали после -I при своём getcert request. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| functional15.crt — Входной файл выданного клиентского сертификата. Откуда взять: Использовать результат getcert request из пути -f; при работе в другом каталоге указать полный путь к этому файлу. |
Где: Терминал Linux на учебном клиенте, каталог /root/functional15.
Что подставить
| root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. | |
| issuing-ca.crt — Входной сертификат промежуточного выдающего центра для построения проверяемой цепочки. Откуда взять: Взять сертификат издателя своего клиентского сертификата из подготовленной цепочки или GetCACert; это тот сертификат, который использовался в подключении certmonger после -N. | |
| functional15.crt — Входной клиентский сертификат, цепочка которого проверяется. Откуда взять: Взять файл результата своего getcert request из параметра -f; имя должно совпадать с использованным при выпуске. |
О чём урок
Получаем сертификат компьютера Windows через адаптер MS-WSTEP Clearway CA. Проверяем доверие и политику регистрации, запускаем ручной запрос через оснастку сертификатов локального компьютера, а затем сверяем установленный сертификат и запись в реестре центра сертификации.
Длительность
03:57
| Время | Действие |
|---|---|
| 00:00 | Сертификат компьютера через MS-WSTEP. Задаём сценарий ручного получения сертификата компьютера через MS-WSTEP и последующей проверки результата в Windows и Clearway CA. |
| 00:21 | Проверяем контекст и доверие. В оснастке сертификатов локального компьютера проверяем контекст работы и наличие доверенного сертификата учебного корневого центра. |
| 00:50 | Проверяем политику регистрации. Открываем управление политиками регистрации и свойства ClearwayCAPolicy, проверяем адрес службы CEP и встроенную аутентификацию Windows. |
| 01:20 | Запускаем запрос. В личном хранилище запускаем мастер запроса нового сертификата и выбираем доступную политику регистрации. |
| 01:44 | Выбираем доступный шаблон. Выбираем доступный шаблон tls и проверяем параметры запроса для компьютера WS01. |
| 02:09 | Получаем сертификат. Запускаем регистрацию и дожидаемся успешного получения сертификата в мастере Windows. |
| 02:31 | Проверяем сертификат в Windows. Открываем полученный сертификат в личном хранилище компьютера, проверяем наличие закрытого ключа, имя, сроки и путь сертификации. |
| 03:01 | Сверяем запись в центре. Находим соответствующий выпуск в реестре Clearway CA и сопоставляем запрос компьютера WS01$, субъект, SAN и серийный номер. |
| 03:32 | Проверенный результат. Подводим итог: сертификат установлен в контексте локального компьютера и сопоставлен с записью центра сертификации. |
О чём урок
Заменяем TLS-сертификат учебного nginx через типовую задачу Clearway CA с сохранением существующего ключа. Проверяем исходный сертификат и пути файлов, выполняем замену, затем подтверждаем доступность HTTPS и соответствие сертификата, который отдаёт сервис.
Длительность
02:51
| Время | Действие |
|---|---|
| 00:00 | Плановая замена сертификата nginx. Обозначаем отдельный учебный экземпляр nginx и плановую замену его сертификата с последующей проверкой HTTPS. |
| 00:28 | Фиксируем исходный сертификат. Через OpenSSL фиксируем исходные поля сертификата и через curl проверяем ответ учебного HTTPS-сервиса на порту 9445. |
| 00:45 | Подключаемся к серверу. В типовой задаче замены сертификата nginx задаём SSH-подключение к учебному серверу и проверяем возможность подключения. |
| 01:04 | Проверяем пути. Проверяем пути к server.crt и server.key в каталоге учебного nginx и наличие обоих файлов. |
| 01:18 | Выбираем режим и шаблон. Выбираем режим «Обновить с тем же ключом» и шаблон video17-nginx; проверяем параметры замены и оставляем автоматический перезапуск выключенным. |
| 01:38 | Выполняем замену. Запускаем замену в Контрольной панели и проверяем сообщение об успешном завершении и данные выпущенного сертификата. |
| 01:55 | Обновляем учебный экземпляр. В терминале читаем заменённый файл сертификата и сверяем новый серийный номер, сроки и DNS SAN guide17.example.test. |
| 02:12 | Проверяем HTTPS. Проверяем HTTPS с доверенным корневым сертификатом, затем через TLS-соединение получаем сертификат сервиса и сверяем серийный номер и SAN. |
| 02:35 | Замена проверена на сервисе. Сравниваем SHA-256 открытых ключей сертификатов до и после замены и подтверждаем сохранение ключа и доступность учебного сервиса. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| /var/lib/clearway-functional-services/nginx/server.crt — Входной файл TLS-сертификата проверяемого экземпляра nginx. Откуда взять: Взять фактический путь из конфигурации nginx и поля «Путь к сертификату» выполненной типовой задачи; до замены читается исходный файл, после — заменённый. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Здесь показан исходный сертификат учебного сервиса как файл доверия; после замены используется ca-root.crt.
Что подставить
| guide17.example.test — DNS-имя HTTPS-сервиса; используется в URL, SNI и проверке имени либо в записи --resolve. Откуда взять: Взять имя, по которому клиенты обращаются к своему nginx, и сверить его с DNS SAN установленного сертификата; во всех позициях команды использовать согласованное имя. | |
| 9445 — TCP-порт проверяемого HTTPS-экземпляра nginx; в URL и --resolve/-connect должен совпадать. Откуда взять: Взять порт из listen соответствующего виртуального сервера nginx или из опубликованного адреса сервиса; 9445 относится только к учебному экземпляру. | |
| 172.27.126.44 — IP-адрес сервера nginx, к которому фактически устанавливается соединение. Откуда взять: Взять адрес своего сервера из схемы размещения и сетевой конфигурации; для --resolve это адрес узла, обслуживающего указанные DNS-имя и порт. | |
| /var/lib/clearway-functional-services/nginx/server.crt — Файл доверия для исходного HTTPS-соединения, переданный curl через --cacert. В учебном кадре эту роль выполняет исходный сертификат самого nginx. Откуда взять: Используйте заранее проверенный файл доверия для исходного сертификата сервиса: для самоподписанного сертификата стенда — его доверенную копию, для сертификата от центра — доверенный корень его цепочки. Путь из ssl_certificate показывает установленный сертификат, но сам по себе не подтверждает доверие к нему. | |
| https:// и завершающий / задают HTTPS-запрос к корню сервиса; домен и порт в URL заменить согласованно с --resolve. Значение --noproxy * здесь отключает прокси для проверки стенда и не является именем сервера. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| /var/lib/clearway-functional-services/nginx/server.crt — Входной файл TLS-сертификата проверяемого экземпляра nginx. Откуда взять: Взять фактический путь из конфигурации nginx и поля «Путь к сертификату» выполненной типовой задачи; до замены читается исходный файл, после — заменённый. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| guide17.example.test — DNS-имя HTTPS-сервиса; используется в URL, SNI и проверке имени либо в записи --resolve. Откуда взять: Взять имя, по которому клиенты обращаются к своему nginx, и сверить его с DNS SAN установленного сертификата; во всех позициях команды использовать согласованное имя. | |
| 9445 — TCP-порт проверяемого HTTPS-экземпляра nginx; в URL и --resolve/-connect должен совпадать. Откуда взять: Взять порт из listen соответствующего виртуального сервера nginx или из опубликованного адреса сервиса; 9445 относится только к учебному экземпляру. | |
| 172.27.126.44 — IP-адрес сервера nginx, к которому фактически устанавливается соединение. Откуда взять: Взять адрес своего сервера из схемы размещения и сетевой конфигурации; для --resolve это адрес узла, обслуживающего указанные DNS-имя и порт. | |
| ca-root.crt — Входной файл доверенного корневого сертификата для проверки нового TLS-сертификата сервиса. Откуда взять: Сохранить корневой сертификат центра, выпустившего сертификат сервиса, из доверенного источника или результатов установки; указать путь относительно рабочего каталога. | |
| DNS-имя и порт входят и в URL https://…/, и в --resolve: заменить обе позиции согласованно. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| 172.27.126.44 — IP-адрес сервера nginx, к которому фактически устанавливается соединение. Откуда взять: Взять адрес своего сервера из схемы размещения и сетевой конфигурации; для --resolve это адрес узла, обслуживающего указанные DNS-имя и порт. | |
| 9445 — TCP-порт проверяемого HTTPS-экземпляра nginx; в URL и --resolve/-connect должен совпадать. Откуда взять: Взять порт из listen соответствующего виртуального сервера nginx или из опубликованного адреса сервиса; 9445 относится только к учебному экземпляру. | |
| guide17.example.test — DNS-имя HTTPS-сервиса; используется в URL, SNI и проверке имени либо в записи --resolve. Откуда взять: Взять имя, по которому клиенты обращаются к своему nginx, и сверить его с DNS SAN установленного сертификата; во всех позициях команды использовать согласованное имя. | |
| ca-root.crt — Входной файл доверенного корневого сертификата для проверки нового TLS-сертификата сервиса. Откуда взять: Сохранить корневой сертификат центра, выпустившего сертификат сервиса, из доверенного источника или результатов установки; указать путь относительно рабочего каталога. | |
| /dev/null — стандартное устройство Linux для перенаправления потоков, свой файл вместо него подставлять не требуется. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| before.crt — Входной сохранённый сертификат nginx до замены. Откуда взять: Перед выполнением типовой задачи сохранить копию исходного сертификата под выбранным именем и указать путь к этой копии. |
Где: Терминал Linux на учебном сервере, каталог functional17; nginx слушает 9445.
Что подставить
| after.crt — Входной сохранённый сертификат nginx после замены. Откуда взять: Сохранить новый сертификат после типовой задачи или после получения сертификата с TLS-сервиса; указать имя этой копии для сравнения с исходным ключом. |
О чём урок
Заменяем TLS-сертификат отдельного учебного кластера PostgreSQL через типовую задачу Clearway CA с созданием нового ключа. После замены перечитываем настройки кластера и проверяем новое подключение с sslmode=verify-full, параметры TLS и сертификат, который отдаёт PostgreSQL.
Длительность
02:49
| Время | Действие |
|---|---|
| 00:00 | Сертификат учебной PostgreSQL. Обозначаем отдельный учебный кластер PostgreSQL на порту 55432 и порядок проверки TLS до и после замены. |
| 00:25 | Проверяем исходное подключение. Читаем исходный сертификат и выполняем SQL-запрос через psql с проверкой DNS-имени и доверия, чтобы подтвердить TLS исходного подключения. |
| 00:46 | Открываем типовую задачу. В Контрольной панели открываем типовую задачу замены сертификата PostgreSQL и задаём SSH-подключение к учебному серверу. |
| 01:04 | Выбираем файлы. Указываем и проверяем пути к server.crt и server.key учебного экземпляра PostgreSQL. |
| 01:19 | Задаём параметры замены. Выбираем замену с новым ключом и шаблон video18-postgres, проверяем DNS SAN guide18.example.test; автоматический перезапуск в форме оставляем выключенным. |
| 01:37 | Выполняем замену. Запускаем замену и проверяем успешное завершение операции и сведения нового сертификата. |
| 01:52 | Перечитываем настройки учебного кластера. В терминале проверяем заменённый сертификат и выполняем reload именно кластера PostgreSQL 16 functional18. |
| 02:11 | Проверяем новое TLS-соединение. Создаём новое подключение psql с sslmode=verify-full и доверенным корневым сертификатом, проверяем ssl=t и TLSv1.3, затем читаем сертификат через PostgreSQL STARTTLS. |
| 02:33 | База доступна по TLS. Подтверждаем, что база guide18 доступна по TLS с новым сертификатом и правильным DNS-именем. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Что подставить
| /var/lib/clearway-functional-services/postgres/server.crt — Входной файл TLS-сертификата учебного кластера PostgreSQL. Откуда взять: Взять фактический путь ssl_cert_file из конфигурации своего кластера и сопоставить с полем сертификата типовой задачи замены. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Что подставить
| cwguide — В примере это и пользователь Linux после sudo -u, и роль PostgreSQL в user=. В своей среде эти имена могут различаться. Откуда взять: Имя после sudo -u взять из учётной записи ОС, от которой разрешён запуск клиента; user= — из созданной роли PostgreSQL с доступом к проверяемой базе. | |
| guide18.example.test — DNS-имя PostgreSQL, которое проверяется по сертификату; используется как host либо как SNI и проверяемое имя. Откуда взять: Взять сервисное DNS-имя своей базы данных и проверить, что оно есть в DNS SAN её TLS-сертификата. | |
| 127.0.0.1 — Адрес, по которому открывается TCP-соединение с PostgreSQL. Здесь база доступна с той же машины. Откуда взять: Использовать loopback только для локального кластера; иначе взять адрес сервера из сетевой конфигурации своей базы. DNS-имя для проверки сертификата задаётся отдельно. | |
| 55432 — TCP-порт отдельного учебного кластера PostgreSQL. Откуда взять: Взять значение port из конфигурации своего кластера или опубликованного подключения; не переносить учебный порт без проверки. | |
| guide18 — Имя базы данных в параметре dbname. Откуда взять: Взять имя существующей базы из настроек приложения или списка баз своего кластера; выбранная роль PostgreSQL должна иметь право подключения. | |
| /var/lib/clearway-functional-services/postgres/server.crt — Файл доверия для проверки исходного TLS-соединения с PostgreSQL, указанный в sslrootcert. В учебном примере используется исходный server.crt. Откуда взять: Укажите заранее проверенный файл доверия для исходного сертификата PostgreSQL: доверенную копию самоподписанного сертификата стенда либо доверенный корневой сертификат его цепочки. Файл должен быть доступен пользователю ОС, запускающему psql; значение ssl_cert_file на сервере само по себе не задаёт клиентское доверие. | |
| Здесь server.crt используется также как исходный файл доверия sslrootcert. sslmode=verify-full, имена параметров подключения, SQL-функции и столбцы в показанной проверке не являются пользовательскими подстановками. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Что подставить
| /var/lib/clearway-functional-services/postgres/server.crt — Входной файл TLS-сертификата учебного кластера PostgreSQL. Откуда взять: Взять фактический путь ssl_cert_file из конфигурации своего кластера и сопоставить с полем сертификата типовой задачи замены. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Команда относится к кластеру functional18; имя и версия кластера заданы для учебного стенда.
Что подставить
| 16 — Установленная основная версия PostgreSQL, к которой относится кластер. Откуда взять: Взять версию своего целевого кластера из сведений об установленном PostgreSQL и конфигурации служб; не переносить число 16 на другую версию. | |
| functional18 — Имя конкретного кластера PostgreSQL, настройки которого перечитываются. Откуда взять: Взять имя кластера из конфигурации служб своего сервера и сопоставить с нужной базой, портом и путями сертификата; это не имя базы данных. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Что подставить
| cwguide — В примере это и пользователь Linux после sudo -u, и роль PostgreSQL в user=. В своей среде эти имена могут различаться. Откуда взять: Имя после sudo -u взять из учётной записи ОС, от которой разрешён запуск клиента; user= — из созданной роли PostgreSQL с доступом к проверяемой базе. | |
| guide18.example.test — DNS-имя PostgreSQL, которое проверяется по сертификату; используется как host либо как SNI и проверяемое имя. Откуда взять: Взять сервисное DNS-имя своей базы данных и проверить, что оно есть в DNS SAN её TLS-сертификата. | |
| 127.0.0.1 — Адрес, по которому открывается TCP-соединение с PostgreSQL. Здесь база доступна с той же машины. Откуда взять: Использовать loopback только для локального кластера; иначе взять адрес сервера из сетевой конфигурации своей базы. DNS-имя для проверки сертификата задаётся отдельно. | |
| 55432 — TCP-порт отдельного учебного кластера PostgreSQL. Откуда взять: Взять значение port из конфигурации своего кластера или опубликованного подключения; не переносить учебный порт без проверки. | |
| guide18 — Имя базы данных в параметре dbname. Откуда взять: Взять имя существующей базы из настроек приложения или списка баз своего кластера; выбранная роль PostgreSQL должна иметь право подключения. | |
| /var/lib/clearway-functional-services/postgres/ca-root.crt — Входной файл доверенного корневого сертификата для libpq в параметре sslrootcert. Откуда взять: Сохранить доверенный корневой сертификат центра, выпустившего новый сертификат PostgreSQL, и указать фактический доступный пользователю Linux путь. | |
| sslmode=verify-full и SQL-запрос к pg_stat_ssl сохраните для проверки имени сервера, доверия и текущего TLS-соединения; имена SQL-функций и столбцов не подставляются из вашей базы. |
Где: Терминал Linux на учебном сервере, каталог functional18; кластер PostgreSQL 16 functional18, порт 55432.
Что подставить
| 127.0.0.1 — Адрес, по которому открывается TCP-соединение с PostgreSQL. Здесь база доступна с той же машины. Откуда взять: Использовать loopback только для локального кластера; иначе взять адрес сервера из сетевой конфигурации своей базы. DNS-имя для проверки сертификата задаётся отдельно. | |
| 55432 — TCP-порт отдельного учебного кластера PostgreSQL. Откуда взять: Взять значение port из конфигурации своего кластера или опубликованного подключения; не переносить учебный порт без проверки. | |
| guide18.example.test — DNS-имя PostgreSQL, которое проверяется по сертификату; используется как host либо как SNI и проверяемое имя. Откуда взять: Взять сервисное DNS-имя своей базы данных и проверить, что оно есть в DNS SAN её TLS-сертификата. | |
| ca-root.crt — Входной файл доверенного корневого сертификата для проверки нового TLS-сертификата сервиса. Откуда взять: Сохранить корневой сертификат центра, выпустившего сертификат сервиса, из доверенного источника или результатов установки; указать путь относительно рабочего каталога. | |
| postgres после -starttls обозначает протокол, а /dev/null — стандартное устройство Linux; эти значения не являются именами вашей базы или файла сертификата. |
О чём урок
Разбираем поиск операции в журнале событий Clearway CA: от фильтра по периоду и типу события до запроса, исполнителя и подробностей результата. Затем открываем историю сертификата, выгружаем отфильтрованный отчёт и проверяем его содержимое в табличном редакторе.
Длительность
03:50
| Время | Действие |
|---|---|
| 00:00 | Найдём историю операции. Задаём задачу: найти историю конкретной операции и получить проверяемую выборку событий. |
| 00:22 | Открываем журнал событий. Открываем журнал событий и знакомимся с датой, типом операции, кодом ошибки, исполнителем, идентификатором запроса и серийным номером сертификата. |
| 00:45 | Ограничиваем период и тип операции. Ограничиваем период поиска и выбираем тип события CA, чтобы сузить список выпусков сертификатов. |
| 01:11 | Находим операцию по запросу. Добавляем фильтр по идентификатору запроса 35 и находим относящееся к нему событие. |
| 01:37 | Читаем результат и подробности. Читаем код результата, исполнителя и дополнительные данные найденного события; прокручиваем таблицу к полям подробностей. |
| 02:06 | Открываем историю сертификата. Открываем события из карточки сертификата и просматриваем связанную последовательность CA, REVOKE и REPAIR. |
| 02:31 | Готовим выборку к выгрузке. Возвращаемся к нужной выборке журнала, проверяем фильтры и параметры выгрузки отчёта. |
| 02:57 | Проверяем скачанный отчёт. Открываем скачанный табличный отчёт и сверяем его строки и поля с найденной операцией. |
| 03:26 | Операция найдена, отчёт проверен. Подтверждаем, что операция найдена по идентификатору запроса, её результат прочитан, а выгрузка содержит нужную историю. |
О чём урок
Учимся читать статистику Clearway CA с учётом выбранного центра и времени последнего расчёта. Сравниваем сведения Контрольной панели с текущей проверкой mclient ping и показателями mclient stat, а также различаем ожидание первого расчёта и ошибку загрузки данных.
Длительность
04:30
| Время | Действие |
|---|---|
| 00:00 | Проверяем состояние ЦС. Разделяем проверку доступности центра сертификации сейчас и просмотр статистики, рассчитанной ранее по расписанию. |
| 00:25 | Проверяем выбранный центр. В настройках проверяем активное подключение minica и соответствующий ему центр сертификации. |
| 00:50 | Находим время расчёта. На странице статистики находим время «Данные собраны» и расписание обновления, чтобы правильно понимать актуальность значений. |
| 01:19 | Читаем сведения о центре. Читаем имя и идентификатор ключа центра, версию и показанный статус службы с учётом времени расчёта. |
| 01:41 | Разбираем количества сертификатов. Разбираем числа действующих, отозванных и истёкших сертификатов и связанные показатели базы. |
| 02:10 | Настраиваем удобный вид. Настраиваем расположение и размеры виджетов, чтобы удобнее сравнивать сведения о центре и сертификатах. |
| 02:37 | Проверяем доступность сейчас. В терминале выполняем mclient ping, сохраняем вывод и проверяем ответ службы, версию, SKI и код результата. |
| 03:07 | Получаем текущие показатели. Выполняем mclient stat, сохраняем вывод и сопоставляем текущие значения со статистикой Контрольной панели. |
| 03:37 | Отличаем ожидание расчёта от ошибки. Разбираем состояния «Статистика ещё не собрана» и «Ошибка загрузки данных»; учитываем, что открытие страницы не запускает пересчёт. |
| 04:07 | Время и состояние проверены. Фиксируем выбранный центр и время получения данных: для текущей доступности используем ping, для текущих количественных показателей — stat. |
Где: Терминал Linux на сервере с настроенным mclient, каталог /opt/itc/minica.
Что подставить
| /home/itc-svc/video-guide-20/ping.txt — Выходной файл для сохранения результата проверки mclient ping через tee. Откуда взять: Выбрать путь в существующем каталоге, доступном на запись учётной записи запуска mclient; при повторном запуске tee перезапишет этот файл. |
Где: Терминал Linux на сервере с настроенным mclient, каталог /opt/itc/minica.
Что подставить
| /home/itc-svc/video-guide-20/stat.txt — Выходной файл для сохранения текущей статистики mclient stat через tee. Откуда взять: Выбрать путь в существующем доступном для записи каталоге; имя можно выбрать самостоятельно, а содержимое использовать для сравнения с Контрольной панелью. |
О чём урок
Показываем ручное создание резервной копии и проверку восстановления отдельного учебного центра сертификации Clearway CA. Проверяем состав задания, создаём копию, добавляем контрольную запись после неё и убеждаемся, что восстановление возвращает данные к выбранному моменту.
Длительность
04:05
| Время | Действие |
|---|---|
| 00:00 | Копия и проверка восстановления. Обозначаем учебный сценарий резервного копирования и восстановления с контрольной записью для проверки результата. |
| 00:28 | Проверяем центр и задание. Проверяем выбранный центр сертификации и открываем подготовленное задание Daily. |
| 00:53 | Что входит в копию. Просматриваем состав задания: базу центра, узел и настроенные файлы; уточняем, что именно входит в эту копию. |
| 01:15 | Запускаем копирование. Запускаем задание вручную, подтверждаем действие и следим за завершением копирования. |
| 01:35 | Проверяем готовую копию. Проверяем готовую копию в списке: время создания, успешный результат и размер архива. |
| 02:01 | Контрольная запись после копии. Создаём контрольный сертификат после сохранения копии и фиксируем появление новой записи в реестре. |
| 02:21 | Выбираем точку восстановления. Выбираем ранее созданную копию и открываем восстановление; сравниваем текущие количества записей с состоянием в копии. |
| 02:45 | Подтверждаем восстановление. Читаем предупреждение о замене данных, подтверждаем восстановление учебного центра и дожидаемся завершения. |
| 03:12 | Проверяем восстановленные данные. Проверяем реестр после восстановления: созданная после копии контрольная запись отсутствует, количество записей соответствует сохранённому состоянию. |
| 03:38 | Восстановление проверено. Подводим итог проверенного восстановления и отмечаем, что изменения после выбранной копии требуют отдельного учёта. |
О чём урок
Продлеваем сертификат выдающего центра сертификации Clearway CA с сохранением его ключа: создаём запрос, подписываем его на родительском центре и устанавливаем полученный сертификат. Затем обновляем публикацию AIA и проверяем выпуск конечного сертификата, цепочки доверия и ответы OCSP до и после отзыва учебного сертификата.
Длительность
05:24
| Время | Действие |
|---|---|
| 00:00 | Продление сертификата центра. Разбираем продление сертификата центра сертификации на примере выдающего центра с сохранением существующего ключа. |
| 00:30 | Проверяем исходный сертификат. Выбираем training-issuing и фиксируем исходные subject, issuer, серийный номер, SKI и сроки сертификата. |
| 00:58 | Выбираем продление. В разделе ротации выбираем продление сертификата на действующем ключе и создаём запрос на сертификат. |
| 01:22 | Скачиваем созданный запрос. Скачиваем сформированный CSR и подготавливаем его для подписания на родительском центре. |
| 01:46 | Подписываем на родительском центре. На родительском центре подписываем CSR через mclient по шаблону subca, проверяем поля сертификата, CA-расширения и подпись родительского центра. |
| 02:20 | Устанавливаем новый сертификат. В Контрольной панели выдающего центра выбираем полученный файл, проверяем его сведения и устанавливаем новый сертификат. |
| 02:51 | Сравниваем результат. Сравниваем результат с исходными данными: проверяем новые срок действия и серийный номер при сохранённом SKI ключа. |
| 03:17 | Обновляем публикацию. Обновляем файл сертификата в публикации AIA, скачиваем его по опубликованному URL и сравниваем контрольные суммы. |
| 03:47 | Проверяем выпуск и статусы. Выпускаем учебный конечный сертификат, проверяем цепочки нового и ранее выпущенного сертификатов, затем проверяем OCSP, отзываем учебный сертификат и повторяем OCSP-проверку. |
| 04:25 | Сертификат корневого центра. Разбираем особенности сертификата корневого центра и отличие его самоподписанного сертификата от сертификата выдающего центра. |
| 04:53 | Продление выполнено и проверено. Сопоставляем проверки: сертификат центра продлён с прежним ключом, опубликованная копия обновлена, выпуск и проверка статусов работают. |
Где: Терминал Linux на родительском центре video-root, каталог /opt/itc/minica; клиент mclient настроен для этого центра.
Что подставить
| /home/itc-svc/video-guide-22/renewal.csr — Входной CSR выдающего центра, сформированный для продления на прежнем ключе. Откуда взять: Скачать запрос в разделе ротации выдающего центра на предыдущем шаге и перенести его на родительский центр; указать фактический путь к этому CSR. | |
| subca — Имя шаблона, по которому родительский центр выпускает сертификат подчинённого центра. Откуда взять: Взять точное имя доступного шаблона в реестре родительского центра и проверить назначение для сертификата центра, CA-расширения и разрешённые параметры. | |
| /home/itc-svc/video-guide-22/renewed-issuing.crt — Выходной файл продлённого сертификата выдающего центра. Откуда взять: Выбрать путь для результата на родительском сервере; этот файл далее проверяется и загружается в выдающий центр. |
Где: Терминал Linux на родительском центре video-root, каталог /opt/itc/minica; клиент mclient настроен для этого центра.
Что подставить
| /home/itc-svc/video-guide-22/renewed-issuing.crt — Входной сертификат выдающего центра, выпущенный родительским центром. Откуда взять: Взять файл, сохранённый предыдущей командой mclient ca в параметре -out; использовать выбранное при выпуске имя. |
Где: Терминал Linux на родительском центре video-root, каталог /opt/itc/minica; клиент mclient настроен для этого центра.
Что подставить
| /opt/itc/minica/ca/ca.crt — Входной доверенный сертификат родительского корневого центра на сервере video-root. Откуда взять: Взять путь к действующему сертификату родительского центра из его каталога установки и конфигурации; здесь проверка выполняется на родительском сервере. | |
| /home/itc-svc/video-guide-22/renewed-issuing.crt — Входной продлённый сертификат выдающего центра, подпись которого проверяется. Откуда взять: Использовать файл результата предыдущего mclient ca по CSR продления; имя совпадает с ранее выбранным -out. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| /opt/itc/minica/ca/ca.crt — Исходный файл уже установленного продлённого сертификата выдающего центра на сервере video-issuing. Откуда взять: Взять путь к текущему сертификату именно выдающего центра из его конфигурации после успешной замены; такой же путь на корневом сервере означает другой сертификат. | |
| /opt/itc/web/aia/Clearway_Training_Issuing_CA.crt — Целевой файл публикации AIA, который заменяется актуальным сертификатом выдающего центра. Откуда взять: Взять каталог и имя из конфигурации своего сервиса публикации и сопоставить с AIA URL сертификатов; не выбирать произвольное имя, если оно уже закреплено в опубликованных адресах. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| http://issuing-ca.example.test/aia/Clearway_Training_Issuing_CA.crt — Полный опубликованный HTTP-адрес сертификата выдающего центра: домен, каталог и имя файла. Откуда взять: Возьмите CA Issuers URI из AIA конечного сертификата, выпущенного продлеваемым выдающим центром, либо из настроек публикации сертификата этого центра. Сверьте адрес с файлом, обновлённым предыдущей командой cp. AIA самого выдающего сертификата может указывать на его родительский центр и для этой загрузки не подходит. | |
| published-ca.crt — Выходной локальный файл сертификата, скачанного по адресу AIA. Откуда взять: Выбрать имя результата скачивания в рабочем каталоге; затем передать этот же файл в sha256sum для сравнения. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| issuing-current.crt — Входной файл действующего сертификата выдающего центра после продления. Откуда взять: Сохранить установленный сертификат выдающего центра после шага замены сертификата; использовать этот файл в текущем рабочем каталоге. | |
| published-ca.crt — Входной файл, полученный из публикации AIA для сравнения с установленным сертификатом. Откуда взять: Взять файл из параметра -o предыдущего curl, который скачивал сертификат по опубликованному URL. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| /opt/itc/minica/mclient — Путь к установленному исполняемому файлу mclient. Откуда взять: Взять каталог установки ядра своего центра сертификации из результатов развёртывания; в примере утилита находится в /opt/itc/minica. | |
| after-renewal.csr — Входной CSR учебного конечного TLS-сертификата для проверки выпуска после продления центра. Откуда взять: Создайте и сохраните CSR для своего сервиса с требуемыми Subject и SAN; укажите путь к этому запросу на машине запуска mclient. Соответствующий закрытый ключ остаётся у владельца сертификата и в файл CSR не включается. | |
| tls — Имя шаблона выпуска конечного TLS-сертификата после -template. Откуда взять: Взять точное имя доступного клиенту шаблона из реестра «Шаблоны» нужного центра; проверить его назначение, параметры и права выпуска. | |
| 30 — Запрашиваемый срок действия конечного сертификата в днях после -days. Откуда взять: Выбрать нужный срок для тестового сертификата с учётом ограничений шаблона и центра; 30 дней — значение проверки в ролике. | |
| after-renewal.crt — Выходной файл конечного сертификата после продления центра. Откуда взять: Выбрать имя результата в рабочем каталоге; использовать тот же файл в последующих проверках цепочки и OCSP. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| root-ca.crt — Входной файл доверенного корневого сертификата; используется для проверки доверия, а не создаётся этой командой. Откуда взять: Получить корневой сертификат своего центра из результатов установки, у администратора или из доверенной цепочки центра; указать путь к сохранённому файлу. | |
| issuing-current.crt — Входной файл действующего сертификата выдающего центра после продления. Откуда взять: Сохранить установленный сертификат выдающего центра после шага замены сертификата; использовать этот файл в текущем рабочем каталоге. | |
| after-renewal.crt — Входной файл конечного сертификата, выпущенного после продления сертификата центра. Откуда взять: Использовать файл, сохранённый на предыдущем шаге mclient ca с -out after-renewal.crt, либо своё выбранное при выпуске имя. | |
| before-leaf.crt — Входной конечный сертификат, выпущенный до продления сертификата центра. Откуда взять: Заранее сохранить один из сертификатов, выданных тем же центром до продления; выбрать действующий сертификат для проверки прежней цепочки. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| issuing-current.crt — Входной файл действующего сертификата выдающего центра после продления. Откуда взять: Сохранить установленный сертификат выдающего центра после шага замены сертификата; использовать этот файл в текущем рабочем каталоге. | |
| after-renewal.crt — Входной файл конечного сертификата, выпущенного после продления сертификата центра. Откуда взять: Использовать файл, сохранённый на предыдущем шаге mclient ca с -out after-renewal.crt, либо своё выбранное при выпуске имя. | |
| http://ocsp.example.test:8888/ocsp — Полный адрес OCSP-ответчика: протокол, домен, порт 8888 и маршрут /ocsp. Откуда взять: Взять OCSP URI из расширения Authority Information Access проверяемого сертификата и сверить с опубликованным адресом своего OCSP-сервиса; заменить домен, порт и маршрут согласованно. | |
| chain-current.pem — Входной PEM-файл доверенных сертификатов для проверки подписи OCSP-ответа. Откуда взять: Подготовить актуальную доверенную цепочку своей иерархии после продления сертификата центра; использовать сохранённый PEM-файл, а не файл проверяемого конечного сертификата. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Серийный номер взят из видео и относится к учебному сертификату; операция меняет его статус.
Что подставить
| /opt/itc/minica/mclient — Путь к установленному исполняемому файлу mclient. Откуда взять: Взять каталог установки ядра своего центра сертификации из результатов развёртывания; в примере утилита находится в /opt/itc/minica. | |
| 100000000000000000000014 — Серийный номер учебного конечного сертификата, который будет отозван. Откуда взять: Взять Serial Number собственного тестового сертификата, выпущенного предыдущим mclient ca после продления; сверить с файлом after-renewal.crt или карточкой сертификата, поскольку команда меняет именно его статус. |
Где: Терминал Linux на выдающем центре video-issuing, каталог /home/itc-svc/video-guide-22.
Что подставить
| issuing-current.crt — Входной файл действующего сертификата выдающего центра после продления. Откуда взять: Сохранить установленный сертификат выдающего центра после шага замены сертификата; использовать этот файл в текущем рабочем каталоге. | |
| after-renewal.crt — Входной файл конечного сертификата, выпущенного после продления сертификата центра. Откуда взять: Использовать файл, сохранённый на предыдущем шаге mclient ca с -out after-renewal.crt, либо своё выбранное при выпуске имя. | |
| http://ocsp.example.test:8888/ocsp — Полный адрес OCSP-ответчика: протокол, домен, порт 8888 и маршрут /ocsp. Откуда взять: Взять OCSP URI из расширения Authority Information Access проверяемого сертификата и сверить с опубликованным адресом своего OCSP-сервиса; заменить домен, порт и маршрут согласованно. | |
| chain-current.pem — Входной PEM-файл доверенных сертификатов для проверки подписи OCSP-ответа. Откуда взять: Подготовить актуальную доверенную цепочку своей иерархии после продления сертификата центра; использовать сохранённый PEM-файл, а не файл проверяемого конечного сертификата. |
О чём урок
Разбираем основные операции с сертификатами через mclient в Clearway CA: выбор конфигурации, проверку связи и получение текущей статистики. Выпускаем учебный сертификат по CSR, находим его в базе, проверяем статус и повторно получаем файл, после чего сравниваем его с результатом выпуска.
Длительность
02:59
| Время | Действие |
|---|---|
| 00:00 | Основные операции через mclient. Задаём последовательность работы через mclient: подключение, проверка центра, выпуск и проверка результата. |
| 00:21 | Выбираем конфигурацию клиента. Переходим в каталог утилиты и задаём MCLIENT_CONF с путём к подготовленной конфигурации клиента. |
| 00:45 | Проверяем связь. Выполняем ping и проверяем успешный ответ центра, его версию и SKI. |
| 01:05 | Смотрим текущую статистику. Выполняем stat и читаем текущие показатели центра с кодом результата errno=0. |
| 01:28 | Выпускаем учебный сертификат. Выпускаем сертификат по подготовленному CSR и шаблону tls, сохраняем результат в cli-issued.cer и фиксируем серийный номер. |
| 01:52 | Находим запись и проверяем статус. Находим запись по CN с ограничением числа результатов, затем запрашиваем статус сертификата по серийному номеру. |
| 02:13 | Получаем сертификат из базы. Получаем тот же сертификат из базы в cli-from-db.cer, читаем его поля и сравниваем SHA-256 двух файлов. |
| 02:36 | Подключение и результат проверены. Подтверждаем правильное подключение, успешный выпуск, статус VALID и совпадение полученного из базы файла с первоначальным результатом. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| /opt/itc/minica — Каталог установки ядра центра и утилиты mclient, из которого дальше запускается ./mclient. Откуда взять: Взять каталог из результатов установки своего центра или конфигурации его службы; стандартный каталог примера — /opt/itc/minica. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| /opt/itc/minica/conf/mclient.yml — Входной файл конфигурации mclient, выбираемый переменной MCLIENT_CONF. Откуда взять: Взять подготовленную при развёртывании конфигурацию клиента нужного центра. В ней заданы server-url, key-file, jwt-file и TLS-параметры; MCLIENT_CONF как имя переменной сохраняется. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| Свои значения подставлять не требуется: ping не принимает параметров этого сценария. Выполните его из каталога установленной утилиты после выбора своего файла через MCLIENT_CONF; адрес центра, ключ и JWT берутся из этой конфигурации. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| Свои значения подставлять не требуется: stat запрашивает показатели центра, выбранного конфигурацией MCLIENT_CONF. Утилита ./mclient запускается из своего каталога установки, а не получает адрес центра отдельным аргументом в этой строке. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| /home/itc-svc/video-guide-23-final/video23-terminal.csr — Входной CSR для выпуска конечного сертификата. Откуда взять: Создайте и сохраните CSR для своего сервиса с требуемыми Subject и SAN; укажите путь к этому запросу на машине запуска mclient. Соответствующий закрытый ключ остаётся у владельца сертификата и в файл CSR не включается. | |
| tls — Имя шаблона выпуска конечного TLS-сертификата после -template. Откуда взять: Взять точное имя доступного клиенту шаблона из реестра «Шаблоны» нужного центра; проверить его назначение, параметры и права выпуска. | |
| /home/itc-svc/video-guide-23-final/cli-issued.cer — Выходной файл сертификата, выданного по CSR. Откуда взять: Выбрать имя и путь в доступном для записи каталоге; этот результат затем сравнивается с сертификатом, полученным из базы. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| video23-terminal.example.test — Искомое значение CN сертификата после -cn. Откуда взять: Взять Common Name из собственного CSR, результата выпуска или карточки сертификата; это имя поиска, а не адрес сервера mclient. | |
| 10 — Максимальное число записей в возвращаемой выборке после -num. Откуда взять: Выбрать размер выборки, достаточный для своего поиска; 10 — ограничение в демонстрации, а не идентификатор сертификата. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| 100000000000000000000022 — Серийный номер конкретного сертификата, передаваемый после -serial. Откуда взять: Скопировать номер из результата своего mclient ca, вывода mclient find либо поля Serial Number карточки нужного сертификата в выбранном центре; сверить его с субъектом. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| 100000000000000000000022 — Серийный номер конкретного сертификата, передаваемый после -serial. Откуда взять: Скопировать номер из результата своего mclient ca, вывода mclient find либо поля Serial Number карточки нужного сертификата в выбранном центре; сверить его с субъектом. | |
| /home/itc-svc/video-guide-23-final/cli-from-db.cer — Выходной файл сертификата, получаемого из базы по серийному номеру. Откуда взять: Выбрать отдельное имя результата, чтобы сохранить исходный cli-issued.cer для сравнения; каталог должен существовать и быть доступен на запись. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| /home/itc-svc/video-guide-23-final/cli-from-db.cer — Входной файл сертификата, ранее полученного из базы центра. Откуда взять: Взять файл из параметра -out предыдущего mclient get и указать своё выбранное имя. |
Где: Терминал Linux от имени itc-svc, каталог /opt/itc/minica; файлы примера в /home/itc-svc/video-guide-23-final.
Что подставить
| /home/itc-svc/video-guide-23-final/cli-issued.cer — Первый входной файл — сертификат, сохранённый непосредственно при выпуске. Откуда взять: Взять файл из параметра -out собственного mclient ca. | |
| /home/itc-svc/video-guide-23-final/cli-from-db.cer — Второй входной файл — тот же сертификат, повторно полученный из базы. Откуда взять: Взять файл из параметра -out собственного mclient get для того же серийного номера. |
О чём урок
В уроке создаём, изменяем и удаляем статическую запись Ивана в конфигурации OpenID и запись Елены во внешнем каталоге LDAP. Файлы редактируем вручную в nano, затем применяем изменения отдельными штатными командами. После создания и изменения проверяем новый вход и профиль, после удаления — отсутствие записи и отказ новой авторизации. Команды и фрагменты ниже служат справкой к последовательным действиям урока. Перед повторением сопоставьте имена, пути, роли и параметры каталога со своей установкой.
Длительность
06:09
| Время | Действие |
|---|---|
| 00:00 | Два источника пользователей |
| 00:25 | Подготовка и резервная копия |
| 00:50 | Создание хеша и статической записи |
| 01:38 | Первый вход Ивана |
| 01:59 | Изменение имени и прав |
| 02:33 | Удаление статической записи |
| 03:05 | Подключение внешнего каталога |
| 03:38 | Создание пользователя в LDAP |
| 04:18 | Первый вход Елены |
| 04:38 | Изменение данных и группы |
| 05:12 | Удаление пользователя из LDAP |
| 05:42 | Что проверять после изменений |
