Home » Как настроить и сконфигурировать центр сертификации (CA) на Ubuntu 24
Как настроить и сконфигурировать центр сертификации (CA) на Ubuntu 24

Как настроить и сконфигурировать центр сертификации (CA) на Ubuntu 24

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

Что такое центр сертификации и зачем он нужен

Центр сертификации (CA) — это доверенная система, которая выдает и управляет цифровыми сертификатами. Принцип работы основан на асимметричной криптографии: CA создает пары ключей (приватный и публичный), подписывает сертификаты своим приватным ключом, а валидация происходит через публичный ключ.

Ключевые преимущества собственного CA:

  • Полный контроль над жизненным циклом сертификатов
  • Отсутствие зависимости от внешних провайдеров
  • Экономия средств для внутренних проектов
  • Возможность создания специализированных сертификатов

Подготовка системы к развертыванию

Для корректной работы CA нужен стабильный сервер с гарантированным аптаймом. Рекомендую использовать надежный VPS или выделенный сервер с Ubuntu 24.04 LTS.

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

sudo apt update && sudo apt upgrade -y
sudo apt install openssl easy-rsa git -y

Создаем специального пользователя для CA и настраиваем директории:

sudo adduser ca-admin
sudo mkdir -p /opt/ca
sudo chown ca-admin:ca-admin /opt/ca
sudo chmod 750 /opt/ca

Конфигурация Easy-RSA

Easy-RSA — это набор скриптов для упрощения управления PKI. Инициализируем структуру:

sudo su - ca-admin
cd /opt/ca
make-cadir ca-infrastructure
cd ca-infrastructure

Редактируем основной конфигурационный файл:

nano vars

Добавляем следующие параметры:

set_var EASYRSA_REQ_COUNTRY     "RU"
set_var EASYRSA_REQ_PROVINCE    "Moscow"
set_var EASYRSA_REQ_CITY        "Moscow"
set_var EASYRSA_REQ_ORG         "MyCompany"
set_var EASYRSA_REQ_EMAIL       "admin@mycompany.com"
set_var EASYRSA_REQ_OU          "IT Department"
set_var EASYRSA_KEY_SIZE        4096
set_var EASYRSA_ALGO            rsa
set_var EASYRSA_CA_EXPIRE       3650
set_var EASYRSA_CERT_EXPIRE     365

Создание корневого сертификата

Инициализируем PKI и создаем корневой CA:

./easyrsa init-pki
./easyrsa build-ca nopass

Система попросит ввести Common Name для CA. Используйте что-то вроде “MyCompany Root CA”.

Проверяем созданный сертификат:

openssl x509 -in pki/ca.crt -text -noout

Настройка промежуточного CA (рекомендуется)

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

Создаем запрос на промежуточный CA:

./easyrsa gen-req intermediate-ca nopass

Подписываем промежуточный CA корневым:

./easyrsa sign-req ca intermediate-ca

Создаем цепочку сертификатов:

cat pki/issued/intermediate-ca.crt pki/ca.crt > pki/intermediate-ca-chain.crt

Автоматизация через скрипты

Создадим удобный скрипт для выдачи серверных сертификатов:

nano /opt/ca/generate-server-cert.sh
#!/bin/bash

if [ $# -ne 1 ]; then
    echo "Usage: $0 "
    exit 1
fi

SERVER_NAME=$1
CA_DIR="/opt/ca/ca-infrastructure"

cd $CA_DIR

# Генерируем запрос на сертификат
./easyrsa gen-req $SERVER_NAME nopass

# Подписываем сертификат
./easyrsa sign-req server $SERVER_NAME

# Создаем bundle для удобства
cat pki/issued/$SERVER_NAME.crt pki/intermediate-ca-chain.crt > pki/issued/$SERVER_NAME-bundle.crt

echo "Certificate generated successfully!"
echo "Certificate: pki/issued/$SERVER_NAME.crt"
echo "Private key: pki/private/$SERVER_NAME.key"
echo "Bundle: pki/issued/$SERVER_NAME-bundle.crt"

Делаем скрипт исполняемым:

chmod +x /opt/ca/generate-server-cert.sh

Практические примеры использования

Создадим сертификат для веб-сервера:

/opt/ca/generate-server-cert.sh web01.mycompany.com

Для создания клиентского сертификата:

cd /opt/ca/ca-infrastructure
./easyrsa gen-req client01 nopass
./easyrsa sign-req client client01

Интеграция с веб-сервером

Пример конфигурации для Nginx:

server {
    listen 443 ssl;
    server_name web01.mycompany.com;
    
    ssl_certificate /opt/ca/ca-infrastructure/pki/issued/web01.mycompany.com-bundle.crt;
    ssl_certificate_key /opt/ca/ca-infrastructure/pki/private/web01.mycompany.com.key;
    
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512;
    ssl_prefer_server_ciphers off;
    
    location / {
        root /var/www/html;
        index index.html;
    }
}

Управление жизненным циклом сертификатов

Создаем скрипт для отзыва сертификатов:

nano /opt/ca/revoke-cert.sh
#!/bin/bash

if [ $# -ne 1 ]; then
    echo "Usage: $0 "
    exit 1
fi

CERT_NAME=$1
CA_DIR="/opt/ca/ca-infrastructure"

cd $CA_DIR

# Отзываем сертификат
./easyrsa revoke $CERT_NAME

# Генерируем новый CRL
./easyrsa gen-crl

echo "Certificate $CERT_NAME revoked successfully!"
echo "Updated CRL: pki/crl.pem"

Мониторинг и обслуживание

Скрипт для проверки срока действия сертификатов:

nano /opt/ca/check-expiry.sh
#!/bin/bash

CA_DIR="/opt/ca/ca-infrastructure"
WARN_DAYS=30

for cert in $CA_DIR/pki/issued/*.crt; do
    if [ -f "$cert" ]; then
        cert_name=$(basename "$cert" .crt)
        expiry_date=$(openssl x509 -enddate -noout -in "$cert" | cut -d= -f2)
        expiry_seconds=$(date -d "$expiry_date" +%s)
        current_seconds=$(date +%s)
        days_until_expiry=$(( ($expiry_seconds - $current_seconds) / 86400 ))
        
        if [ $days_until_expiry -lt $WARN_DAYS ]; then
            echo "WARNING: Certificate $cert_name expires in $days_until_expiry days"
        fi
    fi
done

Сравнение с альтернативными решениями

Решение Простота настройки Возможности Подходит для продакшн
Easy-RSA Высокая Базовые Да
OpenSSL (чистый) Низкая Полные Да
CFSSL Средняя Расширенные Да
Vault PKI Низкая Корпоративные Да

Безопасность и лучшие практики

Критически важные моменты:

  • Храните приватный ключ корневого CA в офлайн-хранилище
  • Используйте сильные пароли для защиты ключей
  • Регулярно обновляйте CRL (Certificate Revocation List)
  • Настройте резервное копирование всей PKI-инфраструктуры
  • Ограничьте доступ к CA только необходимым пользователям

Настройка автоматического бекапа:

nano /opt/ca/backup-ca.sh
#!/bin/bash

BACKUP_DIR="/opt/ca-backup"
CA_DIR="/opt/ca/ca-infrastructure"
DATE=$(date +%Y%m%d-%H%M%S)

mkdir -p $BACKUP_DIR

# Создаем архив
tar -czf $BACKUP_DIR/ca-backup-$DATE.tar.gz -C /opt/ca ca-infrastructure

# Удаляем старые бекапы (старше 30 дней)
find $BACKUP_DIR -name "ca-backup-*.tar.gz" -mtime +30 -delete

echo "Backup completed: $BACKUP_DIR/ca-backup-$DATE.tar.gz"

Интеграция с Docker и Kubernetes

Создание сертификатов для Docker Registry:

/opt/ca/generate-server-cert.sh registry.mycompany.com

Для Kubernetes можно автоматизировать создание сертификатов через cert-manager с собственным CA:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: my-ca-issuer
spec:
  ca:
    secretName: my-ca-secret

Полезные ссылки

Официальная документация:

Заключение и рекомендации

Настройка собственного CA на Ubuntu 24 — это мощный инструмент для обеспечения безопасности корпоративной инфраструктуры. Easy-RSA предоставляет отличный баланс между простотой использования и функциональностью. Для небольших и средних проектов этого решения будет более чем достаточно.

Основные рекомендации:

  • Всегда используйте промежуточный CA для повседневных операций
  • Автоматизируйте рутинные задачи через скрипты
  • Регулярно мониторьте сроки действия сертификатов
  • Настройте надежную систему резервного копирования
  • Документируйте все процедуры и храните документацию в безопасном месте

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


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

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

Leave a reply

Your email address will not be published. Required fields are marked