Возможность

Управление CA

Ваш собственный корень, под ним серверный CA и CA устройств — выпуск, регистрация, отзыв и контроль сроков без выхода за пределы платформы.

TR7 CA Management позволяет выполнять корпоративные mTLS и сертификатные операции полностью на устройстве, без зависимости от внешних командных цепочек. Выпуск клиентских сертификатов, генерация CSR, подписание CA, экспорт P12, разбор сертификатов и конвертация форматов — всё объединено под единой моделью управления. Встроенная PKI-инфраструктура упрощает выпуск сертификатов для сценариев тестирования, staging, B2B API, мобильных устройств, IoT и mTLS. Сертификаты могут создаваться с CN для любого пользователя или устройства, экспортироваться как защищённые парольной фразой P12 и отслеживаться по отпечатку. Файлы сертификатов — не просто загружаемые объекты. Метаданные извлекаются, даты действия парсятся, поля SAN поверхностно отображаются, тип и длина ключа становятся видимыми немедленно. Конвертации PEM и PFX/P12, добавление/удаление парольной фразы и операции с ключами RSA/ECDSA — всё это управляется в одном и том же сертификатном конвейере. Результат: TR7 превращает сертификатные операции из хрупкого, зависимого от экспертов процесса в управляемые объекты сертификатов на ADC — импорт, разбор, подписание, конвертация и распространение — всё в одном месте.

Роли CA в иерархии — корень, серверный CA, CA устройств, у каждого свои профили

2048

бит — размер RSA-ключа по умолчанию, с дайджестом SHA256

365

дней — срок действия по умолчанию; уведомление об истечении за 30 дней

параллельных парсера (fidm + forge) — полное покрытие форматов с резервированием

mTLS — мощный инструмент, но пока PKI-операции остаются сложными, организации не могут применять его повсеместно.

Большинство организаций хотят использовать mTLS, но выпуск сертификатов, управление CA, подготовка CSR, упаковка P12 и распространение среди пользователей оказываются разрозненными между отдельными командами, отдельными инструментами и ручными командами. Модель аутентификации, которая должна быть безопасной, откладывается из-за сложности в эксплуатации или ограничивается лишь несколькими системами.

Проблема ещё более заметна в тестовых и staging-средах. Чтобы команда разработчиков быстро создала тестовый CA, выпустила клиентский сертификат, экспортировала P12 и подключила его к приложению, обычно требуются длинные командные цепочки. Когда этот процесс не стандартизирован, каждая команда изобретает свой подход и управление сертификатами становится фрагментированным.

Распространение клиентских сертификатов — отдельная задача. Создание сертификата для пользователя, устройства, партнёра или IoT-устройства; защита его парольной фразой; встраивание правильной цепочки; запись отпечатка; и повторный выпуск при необходимости — всё это требует операционной дисциплины. Если эта дисциплина не встроена в инструмент, процесс быстро деградирует до ручного обмена файлами.

Ошибки валидации цепочки сертификатов, отсутствующие промежуточные сертификаты, неверные типы ключей, сертификаты, близкие к истечению срока, или неправильные поля SAN — всё это может вызвать прямые сбои. Если CN, SAN, издатель, алгоритм, длина ключа и диапазон действия не видны в момент загрузки сертификата, проблемы обычно обнаруживаются только после того, как пользователи уже затронуты.

Подход TR7 к управлению CA делает PKI доступным и проверяемым, обрабатывая выпуск, подписание, конвертацию, разбор сертификатов и отслеживание истечения срока полностью на устройстве.

Наш подход

TR7 представляет управление CA как встроенный PKI-рабочий процесс, охватывающий выпуск сертификатов, иерархию, валидацию и конвертацию форматов.

Клиентские сертификаты выпускаются на устройстве

TR7 может создать клиентский сертификат из CN и дополнительных полей, сгенерировать CSR, подписать его встроенным CA и выдать P12-результат. Этот процесс не оставляет выпуск mTLS-сертификатов зависимым от внешних командных цепочек.

Цепочка CA и sub-CA поддерживает mTLS-подписание

Встроенный CA-сертификат и ключ могут подписывать клиентские сертификаты. Добавление файла цепочки в P12-результат снижает проблемы с отсутствующей цепочкой на стороне клиента.

Конвейер разбора и валидации извлекает метаданные сертификата

При загрузке сертификата CN, SAN, издатель, алгоритм, длина ключа и даты действия парсятся немедленно. Подход с двумя парсерами обеспечивает более устойчивое извлечение метаданных для сертификатов различных форматов.

PEM, PFX/P12 и форматы ключей конвертируются

TR7 может извлечь ключ и сертификат из PFX или собрать пакет PFX/P12 из PEM-содержимого. Добавление/удаление парольной фразы и операции с типом ключей RSA/ECDSA завершают жизненный цикл сертификата.

Возможности

Управление CA в TR7 охватывает весь жизненный цикл сертификата — внутреннюю иерархию PKI с профилями, регистрацию устройств, отзыв с CRL и OCSP-responder, а также повседневную работу с CSR, подписью и P12 — всё внутри ADC.

Двухуровневая внутренняя PKI — один корень, под ним серверный и устройственный CA

TR7 выпускает сертификаты из собственной иерархии, а не из единственного плоского подписанта: один корень, намеренно неактивный, а под ним серверный CA и CA для устройств. Сертификаты выпускаются по профилям — TLS-сервер, внутренний mTLS, устройство VPN, — поэтому срок действия, алгоритм ключа, расширенное использование ключа и шаблон SAN определяются один раз и применяются каждый раз, а каждый выпущенный сертификат попадает в реестр, по которому можно искать, а не в чей-то домашний каталог. Закрытые ключи живут за абстракцией хранилища ключей — именно это превращает будущий переход на HSM в изменение конфигурации, а не в проект миграции.

Выпуск клиентского сертификата объединяет CSR, подписание CA и P12-результат

Процесс createClientCertificate может выпустить клиентский сертификат с полями CN, passkey, дней действия, email и организации. Генерируется ключ, подготавливается CSR, CA его подписывает и создаётся P12-результат. Результат может включать P12 binary, SHA1-отпечаток, CN и метаданные создания. Это упрощает выпуск mTLS-сертификата для нового пользователя, устройства или партнёра.

Регистрация устройства: ключ создаётся на устройстве и никогда его не покидает

Устройства регистрируются сами: пара ключей создаётся в защищённом элементе телефона или в TPM ноутбука, помечается как неэкспортируемая, и в TR7 уходит только запрос на подпись, который подписывает CA устройств. Никто не отправляет P12 по почте, никто не кладёт закрытый ключ в общую папку, и украденная резервная копия не содержит пригодной личности. Субъектом выпущенного сертификата является собственный идентификатор устройства: устройство — отдельный субъект, не тождественный человеку за ним. Именно это позволяет политике доступа спрашивать про обоих, не смешивая их. Регистрация выполняется по SCEP — протоколу, на котором платформы управления устройствами уже говорят.

Генерация CSR упрощает работу с внешними CA-процессами

TR7 может генерировать CSR с параметризованными полями субъекта. Организация, CN и email добавляются в запрос сертификата контролируемым образом. Организация может подписать с помощью встроенного CA или отправить CSR во внешний корпоративный CA-процесс. TR7 адаптируется как к независимым PKI-потокам, так и к существующим корпоративным процессам подписания.

Подписание CA строит цепочку mTLS-сертификата на устройстве

Клиентские сертификаты могут быть подписаны с использованием встроенного CA-сертификата и CA-ключа. Модель по умолчанию использует дайджест SHA256, RSA 2048-бит и срок действия 365 дней. Подписанный сертификат может служить идентификатором mTLS-клиента. Этот подход снижает необходимость настройки внешнего PKI-сервера для небольших и средних mTLS-сценариев.

Отзыв, который действительно проверяется — CRL и OCSP-responder, а не только stapling

Сертификат отзывается с кодом причины прямо с его собственной страницы, и с этого момента происходит две вещи: он выпадает из ближайшего опубликованного CRL, и встроенный OCSP-responder отвечает по нему «отозван». Именно этот responder большинство платформ оставляет кому-то другому, и именно он позволяет решению о доступе спросить про сертификат за миллисекунды, а не доверять списку, свежему на утро. Обратите внимание на различие: OCSP stapling на фронтенде доказывает, что ваш серверный сертификат ещё действителен, а это доказывает, что клиентский или устройственный сертификат — уже нет.

Операции PFX и P12 обеспечивают двустороннюю конвертацию сертификатов

TR7 может извлечь закрытый ключ и содержимое сертификата из пакета PFX/P12. В обратном направлении — собрать пакет PFX/P12 из ключа и содержимого сертификата. Это упрощает управление сертификатами из Windows-систем или форматами пакетов, требуемыми в разных средах. Формат сертификата перестаёт быть препятствием при миграции приложений.

Операции с ключами RSA и ECDSA поддерживают современные сценарии использования

TR7 может различать тип ключа и обрабатывать сертификатные операции на основе RSA/ECDSA. Операции по защите ключа, такие как добавление или удаление парольной фразы, также могут выполняться в том же конвейере конвертации. Это помогает подготовить ключи из устаревших сервисов для соответствия нуждам современных приложений. Сертификатные операции становятся контролируемой работой с объектами вместо ручного редактирования файлов.

Извлечение метаданных сертификата обеспечивает видимость и проверяемость

При загрузке сертификата поля SAN, CN, издатель, алгоритм, длина ключа, дата начала и дата истечения срока могут быть разобраны. Эта информация доступна для интерфейса и отчётности. Операционная команда может быстро увидеть, какой сертификат охватывает какие доменные имена и когда истекает. Инвентаризация сертификатов больше не зависит от ручных имён файлов.

Генерация SHA1-отпечатка упрощает сопоставление сертификатов

TR7 может извлекать и нормализовать SHA1-отпечаток для сертификата. Значение отпечатка может использоваться для сопоставления клиентских сертификатов, ведения записей и операционного отслеживания. Это особенно полезно в mTLS-идентификаторах клиентов для различения того, какой сертификат принадлежит какому пользователю или устройству. Распространение сертификатов становится более отслеживаемым.

Поддержка построения цепочки встраивает промежуточную цепочку в P12

CA-цепочка может быть включена в пакет при экспорте P12. Это снижает проблемы с цепочкой на стороне клиента, вызванные отсутствующим промежуточным сертификатом. Организация, распространяющая сертификат, может нести необходимую информацию о цепочке внутри одного файла. Это упрощает операции особенно для сценариев распространения на мобильные, настольные устройства и партнёрам.

Уведомление об истечении срока сертификата делает риск сбоя видимым заблаговременно

Модель уведомлений по умолчанию может быть настроена на генерацию предупреждения за 30 дней до истечения срока сертификата. В связке с системой уведомлений оповещения могут доставляться по email, SMS или через другие каналы. Это снижает внезапные производственные сбои из-за истёкших сертификатов. Отслеживание продления сертификатов больше не зависит от ручных напоминаний в календаре.

Операционная глубина

Надёжное управление CA требует совместного рассмотрения путей к файлам, параметров криптографии по умолчанию, очистки временных файлов, санитизации субъекта и изоляции пространства имён.

Пути к файлам сертификатов

Серверный сертификат, CA-сертификат и CA-ключ хранятся по определённым путям в системе. CA-сертификат по /etc/ca.crt и CA-ключ по /etc/ca.key используются для цепочки подписания mTLS. Временный выпуск клиентских сертификатов выполняется в отдельной временной директории.

Параметры криптографии по умолчанию

Выпуск сертификатов по умолчанию использует срок действия 365 дней, размер ключа 2048 бит, дайджест SHA256 и информацию об организации TR7. Это базовые начальные параметры. Срок действия и поля сертификата должны планироваться в соответствии с политикой безопасности организации.

Очистка временных файлов

В процессе выпуска сертификата создаются временные файлы: ключ, CSR, сертификат и P12. Независимо от успешности операции эти файлы очищаются. Такое поведение снижает риск того, что остатки чувствительных закрытых ключей останутся в системе после выпуска.

Санитизация полей субъекта

Специальные символы в полях субъекта, таких как CN, преобразуются в безопасную форму. Это предотвращает проблемы, которые могут возникнуть из-за неожиданных символов при выполнении команд и генерации файлов. Процесс выпуска сертификатов становится более предсказуемым.

Осведомлённость о пространстве имён

Выпуск сертификатов и операции OpenSSL могут выполняться с осведомлённостью о сетевом пространстве имён. Это помогает операциям выполняться в правильном окружении в контексте мультитенантных или изолированных сетей. Сертификатные операции не выходят за рамки модели изоляции тенанта или сети.

Устойчивость двух парсеров

Для разбора сертификатов могут использоваться два различных подхода к парсингу. Если один парсер не справляется с конкретным форматом, другой парсер выступает в роли запасного. Такой дизайн делает извлечение метаданных более устойчивым для сертификатов из разных источников.

Когда применять

Распространение mTLS-клиентских сертификатов на мобильные устройства

Организация может выпустить P12 с уникальным CN и парольной защитой сроком на 1 год для каждого мобильного устройства. Этот результат передаётся на устройство через MDM, и идентификатор клиентского сертификата используется для доступа к AAM или API.

Идентификация по сертификату для B2B-партнёрского API-доступа

Для каждого партнёра может быть выпущен отдельный клиентский сертификат с CN, сопоставленным с идентификатором партнёра. TR7 может отслеживать, какой партнёр достигает какого API через идентификатор сертификата в журналах доступа mTLS.

Выпуск сертификата при онбординге IoT-устройства

Серийный номер IoT-устройства может использоваться как CN, и для каждого устройства может быть выпущен отдельный сертификат. В процессе производства или установки пакет P12 загружается на устройство, и идентификация устройства проверяется через сертификат.

Быстрый self-signed CA в тестовых средах

Команда разработчиков может выпускать краткосрочные сертификаты в staging и распределять их на тестовые backend-сервисы. Поведение mTLS и цепочки сертификатов можно проверить без ожидания внешнего PKI-процесса.

Часто задаваемые вопросы

Может ли TR7 выпускать клиентские сертификаты без внешнего PKI-сервера?

Да. Встроенная CA-инфраструктура TR7 может создать клиентский сертификат с CN и дополнительными полями, подготовить CSR, подписать его с CA и выдать P12-результат. Этот процесс выполняется полностью на устройстве и не требует внешнего PKI-сервера или ручных командных цепочек OpenSSL.

Может ли TR7 быть нашим внутренним CA или он только подписывает клиентские сертификаты?

Это полноценный внутренний CA. Вы создаёте корень, под ним серверный CA и CA устройств, задаёте профили для TLS-сервера, внутреннего mTLS и устройств VPN и выпускаете сертификаты по этим профилям — либо из вставленного CSR, либо из заполненной спецификации. Каждый выпущенный сертификат записывается вместе с профилем, издателем и сроком, а тот же движок подписывает и внутренние TLS-соединения самой платформы, так что доверие внутри кластера перестаёт держаться на выключенной проверке.

Как отозвать сертификат и убедиться, что он действительно перестал работать?

Отзовите его с его собственной страницы, указав код причины. Он выпадает из ближайшего опубликованного CRL, а встроенный OCSP-responder сразу начинает отвечать по нему «отозван» — шлюз или проверка состояния VPN, обращающиеся к OCSP, увидят изменение в ту же секунду, а не при следующем обновлении списка. Кто и почему выполнил отзыв, фиксируется в журнале аудита рядом с записью о выпуске.

Можно ли P12-результат распространять напрямую пользователю или устройству?

Да. P12-результат может быть сгенерирован с парольной защитой и встроенной CA-цепочкой. Это означает, что получатель может установить идентификатор клиента с помощью одного файла, а проблемы из-за отсутствующей промежуточной цепочки снижаются.

Может ли TR7 генерировать CSR для отправки в корпоративный CA?

Да. TR7 может генерировать CSR с параметризованными полями субъекта, включая организацию, CN и email. CSR может быть подписан встроенным CA или отправлен во внешний корпоративный CA-процесс. TR7 поддерживает оба потока.

Как работает конвертация между PFX/P12 и PEM?

TR7 поддерживает двустороннюю конвертацию. Закрытый ключ и сертификат могут быть извлечены из пакета PFX/P12; в обратном направлении пакет PFX/P12 может быть собран из PEM-содержимого. Это упрощает использование сертификатов из Windows-систем в Linux-среде и наоборот.

Как получить уведомление о приближении срока истечения сертификата?

Модель уведомлений по умолчанию может быть настроена на генерацию предупреждения за 30 дней до истечения срока сертификата. Эти уведомления могут быть подключены к потокам email, SMS или других каналов. Отслеживание продления сертификатов больше не зависит от ручных напоминаний в календаре.

Какие криптографические параметры используются для выпуска mTLS-сертификата?

Модель по умолчанию использует размер ключа RSA 2048 бит, дайджест SHA256 и срок действия 365 дней. CA-сертификат хранится по /etc/ca.crt, CA-ключ — по /etc/ca.key. Эти значения должны планироваться в соответствии с политикой безопасности организации.

Управляйте выпуском mTLS-сертификатов на устройстве

Генерация CSR, подписание CA, распространение P12 и отслеживание метаданных сертификатов — без внешнего PKI-сервера. Позвольте нам провести вас через живую настройку в вашей собственной среде.