Home » Создание самоподписанного SSL-сертификата для Apache на Ubuntu 24

Создание самоподписанного SSL-сертификата для Apache на Ubuntu 24

Самоподписанные SSL-сертификаты — это палочка-выручалочка для разработчиков и админов, которые хотят быстро настроить HTTPS на тестовых серверах или в dev-окружении. Да, они не дадут вам зелёный замочек в браузере, но для внутренних проектов, staging-серверов и домашних лабораторий — это именно то, что нужно. Особенно актуально для тех, кто работает с Apache на свежей Ubuntu 24, где некоторые нюансы конфигурации могут отличаться от предыдущих версий.

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

Как работают самоподписанные SSL-сертификаты

Самоподписанный сертификат — это цифровой сертификат, который подписан самим собой, а не доверенным центром сертификации (CA). По сути, вы становитесь собственным CA и говорите браузеру: “Поверь мне, я знаю, что делаю”. Браузер, конечно, не поверит и покажет предупреждение, но для разработки это совершенно нормально.

Процесс работы выглядит так:

Генерируется приватный ключ
Создаётся запрос на сертификат (CSR)
Сертификат подписывается собственным приватным ключом
Apache настраивается для использования этого сертификата

Основное отличие от “настоящих” сертификатов — отсутствие цепочки доверия. Браузер не может проверить подлинность сертификата через известные CA, поэтому показывает предупреждение о безопасности.

Подготовка системы

Для начала убедимся, что у нас установлен Apache и включён SSL-модуль. На Ubuntu 24 процесс стандартный, но лучше перепроверить.

# Обновляем пакеты
sudo apt update && sudo apt upgrade -y

# Устанавливаем Apache, если ещё не установлен
sudo apt install apache2 -y

# Устанавливаем OpenSSL для работы с сертификатами
sudo apt install openssl -y

# Включаем SSL-модуль Apache
sudo a2enmod ssl
sudo a2enmod rewrite

# Перезапускаем Apache
sudo systemctl restart apache2

# Проверяем статус
sudo systemctl status apache2

Если всё прошло успешно, Apache должен быть запущен и готов к работе. Теперь можно переходить к созданию сертификата.

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

Есть несколько способов создать самоподписанный сертификат. Рассмотрим самый простой и быстрый — в одну команду.

# Создаём директорию для сертификатов
sudo mkdir -p /etc/ssl/private
sudo mkdir -p /etc/ssl/certs

# Генерируем приватный ключ и сертификат одной командой
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/ssl/private/apache-selfsigned.key \
    -out /etc/ssl/certs/apache-selfsigned.crt

Система попросит ввести информацию о сертификате. Вот пример заполнения:

Country Name (2 letter code) [AU]: RU
State or Province Name (full name) [Some-State]: Moscow
Locality Name (eg, city) []: Moscow
Organization Name (eg, company) [Internet Widgits Pty Ltd]: My Company
Organizational Unit Name (eg, section) []: IT Department
Common Name (e.g. server FQDN or YOUR name) []: example.local
Email Address []: admin@example.local

Важно: В поле “Common Name” обязательно укажите доменное имя или IP-адрес вашего сервера. Это критично для правильной работы SSL.

Для автоматизации можно использовать параметр -subj:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/ssl/private/apache-selfsigned.key \
    -out /etc/ssl/certs/apache-selfsigned.crt \
    -subj "/C=RU/ST=Moscow/L=Moscow/O=My Company/OU=IT Department/CN=example.local/emailAddress=admin@example.local"

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

# Проверяем права доступа
sudo chmod 600 /etc/ssl/private/apache-selfsigned.key
sudo chmod 644 /etc/ssl/certs/apache-selfsigned.crt

# Смотрим информацию о сертификате
sudo openssl x509 -in /etc/ssl/certs/apache-selfsigned.crt -text -noout

Настройка Apache для SSL

Теперь настроим Apache для работы с нашим сертификатом. Создадим конфигурационный файл для SSL-хоста:

# Создаём конфигурацию для SSL-сайта
sudo nano /etc/apache2/sites-available/default-ssl.conf

Вставляем следующую конфигурацию:

<IfModule mod_ssl.c>
    <VirtualHost *:443>
        ServerName example.local
        DocumentRoot /var/www/html

        # Логи
        ErrorLog ${APACHE_LOG_DIR}/ssl_error.log
        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined

        # SSL конфигурация
        SSLEngine on
        SSLCertificateFile /etc/ssl/certs/apache-selfsigned.crt
        SSLCertificateKeyFile /etc/ssl/private/apache-selfsigned.key

        # Современные SSL настройки
        SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
        SSLCipherSuite ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384
        SSLHonorCipherOrder off
        SSLSessionTickets off

        # Заголовки безопасности
        Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
        Header always set X-Frame-Options DENY
        Header always set X-Content-Type-Options nosniff
    </VirtualHost>
</IfModule>

Также настроим редирект с HTTP на HTTPS:

# Редактируем основной конфиг
sudo nano /etc/apache2/sites-available/000-default.conf

Добавляем редирект:

<VirtualHost *:80>
    ServerName example.local
    DocumentRoot /var/www/html

    # Редирект на HTTPS
    RewriteEngine On
    RewriteCond %{HTTPS} off
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</VirtualHost>

Активируем сайт и необходимые модули:

# Включаем модуль headers для заголовков безопасности
sudo a2enmod headers

# Активируем SSL-сайт
sudo a2ensite default-ssl

# Проверяем конфигурацию
sudo apache2ctl configtest

# Если всё OK, перезапускаем Apache
sudo systemctl restart apache2

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

Для более сложных сценариев можно создать сертификат с поддержкой нескольких доменов (Subject Alternative Names). Это полезно, если у вас несколько поддоменов или вы хотите, чтобы сертификат работал и с IP-адресом.

Создаём конфигурационный файл:

sudo nano /tmp/ssl.conf

Содержимое файла:

[req]
default_bits = 2048
prompt = no
default_md = sha256
req_extensions = req_ext
distinguished_name = dn

[dn]
C = RU
ST = Moscow
L = Moscow
O = My Company
OU = IT Department
CN = example.local

[req_ext]
subjectAltName = @alt_names

[alt_names]
DNS.1 = example.local
DNS.2 = www.example.local
DNS.3 = api.example.local
DNS.4 = admin.example.local
IP.1 = 192.168.1.100
IP.2 = 127.0.0.1

Генерируем сертификат с этими параметрами:

sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/ssl/private/apache-selfsigned.key \
    -out /etc/ssl/certs/apache-selfsigned.crt \
    -config /tmp/ssl.conf

Тестирование и диагностика

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

# Проверяем, что Apache слушает на порту 443
sudo netstat -tlnp | grep :443

# Тестируем SSL соединение
openssl s_client -connect example.local:443 -servername example.local

# Проверяем сертификат через curl
curl -I -k https://example.local

# Детальная информация о сертификате
echo | openssl s_client -servername example.local -connect example.local:443 2>/dev/null | openssl x509 -text -noout

Если возникают проблемы, проверьте логи Apache:

# Основные логи
sudo tail -f /var/log/apache2/error.log
sudo tail -f /var/log/apache2/ssl_error.log

# Проверяем конфигурацию SSL
sudo apache2ctl -S

Сравнение различных подходов

Метод	Плюсы	Минусы	Когда использовать
Простой самоподписанный	Быстро, просто	Только один домен	Простые тестовые сайты
С SAN	Множество доменов, IP	Сложнее настройка	Комплексные dev-среды
Let’s Encrypt	Бесплатно, доверенный CA	Нужен публичный домен	Production-сайты
Коммерческий	Максимальное доверие	Стоит денег	Корпоративные проекты

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

Для автоматизации процесса можно создать bash-скрипт. Вот пример скрипта для массового создания сертификатов:

#!/bin/bash

# ssl-cert-generator.sh

DOMAIN=${1:-example.local}
CERT_DIR="/etc/ssl/certs"
KEY_DIR="/etc/ssl/private"
CERT_FILE="${CERT_DIR}/${DOMAIN}.crt"
KEY_FILE="${KEY_DIR}/${DOMAIN}.key"

echo "Создание SSL сертификата для ${DOMAIN}"

# Создаём директории
sudo mkdir -p ${CERT_DIR} ${KEY_DIR}

# Генерируем сертификат
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout ${KEY_FILE} \
    -out ${CERT_FILE} \
    -subj "/C=RU/ST=Moscow/L=Moscow/O=Dev Company/OU=IT/CN=${DOMAIN}"

# Устанавливаем права
sudo chmod 600 ${KEY_FILE}
sudo chmod 644 ${CERT_FILE}

echo "Сертификат создан:"
echo "Certificate: ${CERT_FILE}"
echo "Private Key: ${KEY_FILE}"

# Проверяем сертификат
sudo openssl x509 -in ${CERT_FILE} -text -noout | grep -E "(Subject|Not After)"

Использование скрипта:

chmod +x ssl-cert-generator.sh
sudo ./ssl-cert-generator.sh mydomain.local

Интеграция с Docker и контейнерами

Самоподписанные сертификаты отлично работают в Docker-контейнерах. Можно создать образ с предустановленными сертификатами:

# Dockerfile
FROM ubuntu:24.04

RUN apt-get update && apt-get install -y \
    apache2 \
    openssl \
    && rm -rf /var/lib/apt/lists/*

# Копируем сертификаты
COPY ssl-cert-generator.sh /usr/local/bin/
COPY apache-ssl.conf /etc/apache2/sites-available/

# Включаем SSL
RUN a2enmod ssl && a2enmod rewrite

EXPOSE 80 443

CMD ["apache2ctl", "-D", "FOREGROUND"]

Для работы с VPS-серверами такой подход особенно удобен — можно быстро разворачивать тестовые среды с SSL.

Работа с мобильными устройствами

Интересный факт: для тестирования мобильных приложений с самоподписанными сертификатами нужно добавить сертификат в доверенные на устройстве. Для Android это делается через Settings → Security → Install certificates.

Для iOS процесс сложнее — нужно отправить сертификат по email, установить его, а затем включить в Settings → General → About → Certificate Trust Settings.

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

Не забывайте отслеживать срок действия сертификатов. Простой скрипт для мониторинга:

#!/bin/bash

# check-ssl-expiry.sh

CERT_FILE="/etc/ssl/certs/apache-selfsigned.crt"
DAYS_WARN=30

if [ ! -f "$CERT_FILE" ]; then
    echo "Сертификат не найден: $CERT_FILE"
    exit 1
fi

EXPIRY_DATE=$(openssl x509 -in "$CERT_FILE" -noout -enddate | cut -d= -f2)
EXPIRY_EPOCH=$(date -d "$EXPIRY_DATE" +%s)
CURRENT_EPOCH=$(date +%s)
DAYS_LEFT=$(( ($EXPIRY_EPOCH - $CURRENT_EPOCH) / 86400 ))

if [ $DAYS_LEFT -lt $DAYS_WARN ]; then
    echo "ВНИМАНИЕ: Сертификат истекает через $DAYS_LEFT дней!"
    echo "Дата истечения: $EXPIRY_DATE"
else
    echo "Сертификат действителен ещё $DAYS_LEFT дней"
fi

Добавьте этот скрипт в cron для автоматической проверки:

# Проверяем каждый день в 9:00
0 9 * * * /usr/local/bin/check-ssl-expiry.sh

Альтернативные решения

Помимо OpenSSL, есть и другие инструменты для создания сертификатов:

mkcert — удобная утилита для создания локальных CA (https://github.com/FiloSottile/mkcert)
easyrsa — часть OpenVPN, но можно использовать отдельно
cfssl — инструмент от CloudFlare для работы с PKI

Пример использования mkcert:

# Установка mkcert
curl -JLO "https://dl.filippo.io/mkcert/latest?for=linux/amd64"
chmod +x mkcert-v*-linux-amd64
sudo mv mkcert-v*-linux-amd64 /usr/local/bin/mkcert

# Создание локального CA
mkcert -install

# Генерация сертификата
mkcert example.local localhost 127.0.0.1 ::1

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

Несколько важных моментов по безопасности:

Права доступа: приватные ключи должны быть доступны только root (600)
Длина ключа: используйте минимум 2048 бит, лучше 4096
Алгоритмы: избегайте SHA-1, используйте SHA-256 или выше
Срок действия: не делайте сертификаты слишком долгоживущими

Для выделенных серверов рекомендую создавать отдельные сертификаты для каждого сервиса и регулярно их обновлять.

Интеграция с CI/CD

В DevOps-процессах самоподписанные сертификаты можно генерировать автоматически. Пример для GitLab CI:

generate_ssl:
  stage: prepare
  script:
    - apt-get update && apt-get install -y openssl
    - mkdir -p ssl/
    - openssl req -x509 -nodes -days 365 -newkey rsa:2048 
      -keyout ssl/server.key -out ssl/server.crt 
      -subj "/C=RU/ST=Moscow/L=Moscow/O=CI/CN=test.local"
  artifacts:
    paths:
      - ssl/
    expire_in: 1 hour

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

Самоподписанные SSL-сертификаты — это мощный инструмент для разработки и тестирования. Они не заменят полноценные сертификаты в production, но для dev-окружения, staging-серверов и внутренних проектов — это идеальное решение.

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

Локальная разработка и тестирование
Внутренние корпоративные сервисы
Staging-среды
Домашние лаборатории
Обучение и эксперименты

Когда НЕ использовать:

Публичные сайты
Коммерческие проекты
Anywhere, где важно доверие пользователей
API для внешних клиентов

Помните: самоподписанные сертификаты обеспечивают шифрование, но не аутентификацию. Для production-среды всегда используйте сертификаты от доверенных CA или Let’s Encrypt.

Ubuntu 24 отлично подходит для таких экспериментов — система стабильная, Apache работает без проблем, а OpenSSL достаточно свежий для всех современных криптографических стандартов. Удачи в настройке!

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

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