- Home »
Создание самоподписанного 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 достаточно свежий для всех современных криптографических стандартов. Удачи в настройке!
В этой статье собрана информация и материалы из различных интернет-источников. Мы признаем и ценим работу всех оригинальных авторов, издателей и веб-сайтов. Несмотря на то, что были приложены все усилия для надлежащего указания исходного материала, любая непреднамеренная оплошность или упущение не являются нарушением авторских прав. Все упомянутые товарные знаки, логотипы и изображения являются собственностью соответствующих владельцев. Если вы считаете, что какой-либо контент, использованный в этой статье, нарушает ваши авторские права, немедленно свяжитесь с нами для рассмотрения и принятия оперативных мер.
Данная статья предназначена исключительно для ознакомительных и образовательных целей и не ущемляет права правообладателей. Если какой-либо материал, защищенный авторским правом, был использован без должного упоминания или с нарушением законов об авторском праве, это непреднамеренно, и мы исправим это незамедлительно после уведомления. Обратите внимание, что переиздание, распространение или воспроизведение части или всего содержимого в любой форме запрещено без письменного разрешения автора и владельца веб-сайта. Для получения разрешений или дополнительных запросов, пожалуйста, свяжитесь с нами.
More stories
