Собственный центр сертификации на Step CA с ACME

Введение

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

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

Сегодня эту задачу можно решить значительно проще. Благодаря Step CA организация может развернуть собственный центр сертификации с поддержкой ACME и получить возможности, которые многие привыкли ассоциировать с Let's Encrypt: автоматический выпуск, продление и управление сертификатами.

В этой статье мы создадим собственный центр сертификации на базе Step CA, настроим автоматическую выдачу сертификатов через ACME, подключим Nginx и Apache, а также настроим доверие для Linux и Windows-систем.

В результате мы получим полностью автономную систему управления сертификатами, не зависящую от внешних центров сертификации и облачных сервисов.

В качестве примера будет использоваться доменная зона tex-lab.ru, вы должны ее заменить на свою!

Важно

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

Если требуется обеспечить доверие для публичных сайтов и сервисов, доступных из глобальной сети Интернет, рекомендуется использовать публичные центры сертификации, такие как Let's Encrypt, Sectigo, DigiCert и другие.

1. Архитектура будущей системы

Перед тем как что-то устанавливать, важно понять итоговую схему.

Из чего будет состоять наша инфраструктура

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

Step CA

Step CA - это открытый центр сертификации с поддержкой ACME, который станет основой всей нашей инфраструктуры.

Во время первоначальной настройки Step CA автоматически создаёт:

• Root CA (корневой центр сертификации);
• Intermediate CA (промежуточный центр сертификации).

После этого Step CA берёт на себя управление всей инфраструктурой сертификатов и предоставляет удобный интерфейс для их автоматической выдачи. По сути, Step CA является собственным аналогом Let's Encrypt, который полностью находится под вашим контролем.

После настройки он сможет:

• автоматически выдавать сертификаты;
• автоматически продлевать сертификаты;
• отзывать сертификаты;
• работать через протокол ACME;
• обслуживать внутренние и внешние сервисы организации.

Root CA

Root CA (Root Certificate Authority) - это корневой центр сертификации и основа доверия всей инфраструктуры. Во время настройки Step CA корневой сертификат создаётся автоматически и используется для формирования цепочки доверия.

Именно этот сертификат необходимо установить на клиентские устройства, серверы и рабочие станции, чтобы они доверяли сертификатам, выпущенным вашим центром сертификации.

В повседневной работе Root CA напрямую не участвует. Его основная задача - подтверждать подлинность Intermediate CA.

---

Intermediate CA

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

Например, сертификаты могут выдаваться для:

• веб-сайтов;
• VPN-серверов;
• почтовых серверов;
• систем мониторинга;
• внутренних сервисов;
• API и веб-приложений.

Такой подход повышает безопасность, поскольку Root CA не используется для ежедневной выдачи сертификатов.

Certbot

Certbot - это ACME-клиент, который устанавливается на серверы и используется для автоматического получения сертификатов.

С его помощью сервер может самостоятельно обратиться к Step CA, получить сертификат и в дальнейшем автоматически продлевать его без участия администратора. Например, после настройки достаточно выполнить одну команду, и сертификат для сайта будет выпущен автоматически.

Такой же принцип используется при работе с Let's Encrypt, однако в нашем случае сертификаты выдаёт собственный центр сертификации Step CA.

2. Установка Step CA (ACME сервер)

Для начала установим необходимые компоненты:

apt-get update && apt-get install -y --no-install-recommends curl gpg ca-certificates

curl -fsSL https://packages.smallstep.com/keys/apt/repo-signing-key.gpg -o /etc/apt/keyrings/smallstep.asc

cat << EOF > /etc/apt/sources.list.d/smallstep.sources
Types: deb
URIs: https://packages.smallstep.com/stable/debian
Suites: debs
Components: main
Signed-By: /etc/apt/keyrings/smallstep.asc
EOF

apt-get update && apt-get -y install step-cli step-ca

После завершения установки убедимся, что утилита доступна в системе:

step version

step-ca version

Если команды отобразили версию установленного ПО, значит установка прошла успешно.

3. Инициализация Step CA

После установки необходимо создать конфигурацию центра сертификации.

Для этого запустим мастер первоначальной настройки:

step ca init

Далее указываем:

• Deployment type: standalone
• Name: tex-lab CA
• DNS: ca.tex-lab.ru
• Address: 0.0.0.0:443
• Name provisioner: a@tex-lab.ru
• Password: Нажмите Enter и Step CA создаст Вам надежный пароль

Далее мастер автоматически создаст Root CA и Intermediate CA. По завершению выдаст Вам все данные.

Обязательно сохраните эти данные!

4. Запуск Step CA

Так как Step CA уже выпустил корневой сертификат и дальше мы будем рабоать с ним, то нам его надо добавить в список доверенных:

cd /root/.step/certs

cp root_ca.crt /usr/local/share/ca-certificates/tex-lab-root.crt

Обновим список сертификат:

update-ca-certificates

После завершения настройки Step CA у нас уже готова конфигурация центра сертификации.

Время жизни выдаваемых сертификатов

Откроем файл ca.json:

nano $(step path)/config/ca.json

добавим блок:

"authority": {
        "claims": {
                "defaultTLSCertDuration": "720h",
                "maxTLSCertDuration": "8760h"
        }
},

Эта настройка задаёт сроки действия TLS-сертификатов в Step CA. Параметр defaultTLSCertDuration определяет срок сертификата по умолчанию (720 часов = 30 дней), если клиент не запросил другой срок. Параметр maxTLSCertDuration ограничивает максимальный срок действия сертификата одним годом (8760 часов).

 

Теперь запустим сам сервис:

step-ca $(step path)/config/ca.json

После запуска Step CA начинает работать как полноценный ACME-сервер и обрабатывать запросы на выдачу сертификатов.

Если всё запущено корректно, сервис будет слушать указанный ранее адрес, например:

https://ca.tex-lab.ru:443

На этом этапе можно проверить, что API центра сертификации доступен. Это означает, что инфраструктура CA успешно поднята и готова к работе.

5. Включение ACME

ACME - это протокол, который позволяет автоматически получать и обновлять SSL-сертификаты. Именно его использует Let's Encrypt, и именно его мы будем использовать внутри своей инфраструктуры.

Чтобы включить поддержку ACME в Step CA, необходимо добавить соответствующий блок в конфигурационный файл ca.json.

Для этого выполним команду:

step ca provisioner add acme --type ACME

После этого Step CA начнёт принимать ACME-запросы от клиентов (например Certbot) и сможет автоматически выдавать сертификаты.

6. Получение первого сертификата (Certbot)

Теперь перейдём к практической части и получим первый сертификат от нашего собственного центра сертификации.

6.1 Установка

Для начала установим Certbot на сервер, где будет использоваться сертификат (например Nginx или Apache):

apt install certbot -y

Certbot будет выступать клиентом ACME и обращаться к нашему Step CA за сертификатом.

6.2 Запрос сертификата

Теперь выполним запрос сертификата для конкретного домена:

certbot certonly \
  --server https://ca.tex-lab.ru/acme/acme/directory \
  -d tex-lab.ru \
  --standalone

Разберём параметры:

• certonly - получить сертификат без автоматической настройки веб-сервера.
• --server - указывает наш ACME-сервер (Step CA), а не Let's Encrypt.
• -d tex-lab.ru - домен, для которого выпускается сертификат.
• --standalone - временно поднимает встроенный HTTP-сервер для проверки владения доменом.

6.3 Что происходит дальше

После выполнения команды происходит следующий процесс:

1. Certbot обращается к Step CA.
2. Step CA проверяет владение доменом tex-lab.ru.
3. Если проверка успешна, выпускается сертификат.
4. Certbot сохраняет сертификат на сервере.

В результате мы получаем полноценный SSL-сертификат, выпущенный нашим собственным центром сертификации.

6.4 Где лежит сертификат

После успешного выполнения команды файлы будут доступны по пути:

/etc/letsencrypt/live/grafana.tex-lab.ru/

Внутри будут:

• fullchain.pem - полный сертификат цепочки доверия.
• privkey.pem - приватный ключ.

Их уже можно использовать в Nginx или Apache для включения HTTPS.

7. Настройка Nginx

Теперь настроим веб-сервер Nginx, который будет использовать выпущенные нами сертификаты для работы по HTTPS.

7.1 Установим Nginx

Команда:

apt install nginx -y

После установки создадим конфигурацию виртуального хоста для сервиса Grafana, который будет доступен по адресу:

https://grafana.tex-lab.ru

7.2 Конфигурация Nginx

server {
    listen 443 ssl;
    server_name grafana.tex-lab.ru;

    ssl_certificate /etc/letsencrypt/live/grafana.tex-lab.ru/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/grafana.tex-lab.ru/privkey.pem;

    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Что здесь происходит:

• listen 443 ssl - включаем HTTPS соединение.
• server_name - указываем домен сервиса.
• ssl_certificate - путь к публичному сертификату.
• ssl_certificate_key - приватный ключ сертификата.
• proxy_pass - проксирование запросов к внутреннему сервису Grafana.

Таким образом Nginx выступает как TLS-терминатор и обратный прокси для внутренних сервисов.

8. Настройка Apache

Теперь рассмотрим аналогичную настройку для Apache.

8.1 Установка Apache

Команда:

apt install apache2 -y

Активируем модуль SSL:

a2enmod ssl

Теперь создадим виртуальный хост для внутренней вики:

https://wiki.tex-lab.ru

8.2 Конфигурация Apache

<VirtualHost *:443>
    ServerName wiki.tex-lab.ru

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/wiki.tex-lab.ru/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/wiki.tex-lab.ru/privkey.pem
</VirtualHost>

Что здесь происходит:

• VirtualHost *:443 - включаем HTTPS виртуальный хост.
• ServerName - домен сайта.
• SSLEngine on - включаем SSL.
• SSLCertificateFile - путь к сертификату.
• SSLCertificateKeyFile - путь к приватному ключу.

В результате Apache будет обслуживать HTTPS-соединения с использованием сертификатов, выданных нашим собственным CA.

9. Автоматическое обновление сертификатов

Одна из ключевых задач ACME - автоматическое продление сертификатов до их истечения. Если этого не сделать, через некоторое время сертификаты начнут истекать, и сервисы перестанут работать по HTTPS.

Включим автоматическое обновление через systemd timer:

systemctl enable certbot.timer
systemctl start certbot.timer

Проверка работы таймера:

systemctl list-timers | grep certbot

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

10. Доверие в Linux

Чтобы Linux-системы перестали выдавать предупреждения о недоверенных сертификатах, необходимо добавить наш Root CA в системное хранилище доверенных центров сертификации.

Скопируем сертификат:

cp root/ca.crt /usr/local/share/ca-certificates/tex-lab.crt

Обновим список доверенных сертификатов:

update-ca-certificates

После этого:

• браузеры на Linux начнут доверять сертификатам;
• curl, wget и другие утилиты будут принимать HTTPS без ошибок;
• системные сервисы смогут проверять TLS-соединения.

11. Доверие в Active Directory (Windows)

В корпоративной среде важно распространить доверие на все рабочие станции. Для этого используется Group Policy (GPO).

Для этого надо:

1. открыть Group Policy Management;
2. Computer Configuration → Policies;
3. Trusted Root Certification Authorities;
4. импортировать ca.crt.

После применения политики:

• все доменные компьютеры начинают доверять нашему Root CA;
• браузеры перестают показывать предупреждения;
• любые сертификаты, выпущенные нашим CA, становятся автоматически доверенными.

12. Пример инфраструктуры tex-lab.ru

Теперь соберём всё, что мы сделали, в единую картину и посмотрим, как это будет выглядеть в реальной инфраструктуре организации.

В качестве примера используем домен tex-lab.ru и набор внутренних сервисов.

ca.tex-lab.ru        → центр сертификации
tex-lab.ru           → основной домен
grafana.tex-lab.ru   → система мониторинга
zabbix.tex-lab.ru    → система мониторинга
wiki.tex-lab.ru      → документация
vpn.tex-lab.ru       → доступ в корпоративную сеть

Каждый из этих сервисов использует HTTPS-сертификаты, выпущенные нашим собственным центром сертификации.

Как это работает на практике

1. Администратор разворачивает новый сервис, например grafana.tex-lab.ru
2. Сервис автоматически запрашивает сертификат через ACME
3. Step CA выпускает сертификат на основе Intermediate CA
4. Certbot устанавливает сертификат на сервер
5. Пользователь открывает сайт без предупреждений браузера

В итоге вся инфраструктура работает в единой системе доверия и не требует ручного управления сертификатами.

13. Отзыв сертификатов

В реальной инфраструктуре важно уметь отзывать сертификаты.

Это нужно в ситуациях, когда:

• приватный ключ сервера был скомпрометирован;
• сервер был взломан;
• сотрудник потерял доступ к системе;
• оборудование выведено из эксплуатации.

Отзыв через Step CA

Если используется Step CA, отзыв сертификата выполняется командой:

step ca revoke \
  --cert /etc/letsencrypt/archive/tex-lab.ru/cert1.pem \
  --key /etc/letsencrypt/archive/tex-lab.ru/privkey1.pem

После этого сертификат попадает в список отозванных и больше не считается доверенным.

14. Резервное копирование CA

Одна из самых критичных частей всей инфраструктуры - это резервное копирование центра сертификации.

Потеря этих данных означает полную потерю доверенной инфраструктуры.

Обязательно сохраняйте резервные копии следующих файлов и каталогов:

• /root/.step/secrets/root_ca_key - приватный ключ корневого центра сертификации (Root CA);
• /root/.step/certs/root_ca.crt - корневой сертификат;
• /root/.step/secrets/intermediate_ca_key - приватный ключ промежуточного центра сертификации (Intermediate CA);
• /root/.step/certs/intermediate_ca.crt - сертификат промежуточного центра сертификации;
• /root/.step/config/ca.json - основная конфигурация Step CA;
• /root/.step/config/defaults.json - параметры подключения клиентов Step;
• /root/.step/db/ - база данных центра сертификации, содержащая информацию о выданных и отозванных сертификатах.

Эти данные нельзя хранить:

• на публичных серверах;
• на серверах с доступом из интернета;
• без шифрования;
• без контроля доступа.

Рекомендуемая практика

• хранить резервную копию в офлайн-хранилище;
• использовать зашифрованные архивы;
• ограничить доступ только администраторам;
• регулярно проверять возможность восстановления.

Заключение

В рамках статьи мы развернули собственный центр сертификации на базе Step CA и настроили автоматическую выдачу сертификатов через ACME.

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

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

При необходимости инфраструктуру можно масштабировать, добавляя новые серверы и сервисы без изменения общей схемы работы.