Apache и HTTPS [208.2]

Рейтинг: 56.5% · 9 голосов
Курс LPIC-2 (201-450 и 202-450): емкостное планирование, ядро, хранилище и RAID/LVM, продвинутая сеть, DNS/BIND, Apache/Nginx, Samba/NFS, DHCP/LDAP, почта, безопасность и VPN.
Ответить
Аватара пользователя
Sergey_Sysadmin
Сообщения: 134
Зарегистрирован: 11 май 2026, 05:31

Apache и HTTPS [208.2]

Сообщение Sergey_Sysadmin »

Оглавление курса (41)
  1. Введение в LPIC-2 и уровень инженера
  2. Измерение и устранение проблем с ресурсами [200.1]
  3. Прогнозирование потребности в ресурсах
  4. Компоненты ядра Linux [201.1]
  5. Сборка ядра из исходников [201.2]
  6. Управление модулями ядра в рантайме [201.3]
  7. Кастомизация запуска системы [202.1]
  8. Восстановление системы [202.2]
  9. Альтернативные загрузчики [202.3]
  10. Работа с файловой системой Linux [203.1]
  11. Обслуживание файловых систем [203.2]
  12. Создание и настройка опций ФС [203.3]
  13. Программный RAID [204.1]
  14. Тюнинг доступа к устройствам хранения [204.2]
  15. Менеджер логических томов LVM [204.3]
  16. Базовая конфигурация сети [205.1]
  17. Продвинутая конфигурация сети [205.2]
  18. Диагностика сетевых проблем [205.3]
  19. Сборка и установка программ из исходников [206.1]
  20. Резервное копирование [206.2]
  21. Оповещение пользователей о событиях
  22. DNS-сервер BIND: базовая настройка [207.1]
  23. Зоны DNS: создание и сопровождение [207.2]
  24. Безопасность DNS-сервера [207.3]
  25. Веб-сервер Apache: базовая настройка [208.1]
  26. Apache и HTTPS [208.2] (вы здесь)
  27. Кэширующий прокси Squid [208.3]
  28. Веб-сервер и обратный прокси Nginx [208.4]
  29. Файловый сервер Samba [209.1]
  30. Файловый сервер NFS [209.2]
  31. DHCP-сервер [210.1]
  32. Аутентификация PAM и SSSD [210.2]
  33. Использование LDAP-клиента
  34. Сервер OpenLDAP [210.4]
  35. Почтовый сервер Postfix [211.1]
  36. Управление доставкой почты и Sieve [211.2]
  37. Доступ к почтовым ящикам: Dovecot [211.3]
  38. Linux как маршрутизатор и фильтр [212.1]
  39. FTP-серверы [212.2]
  40. SSH углублённо [212.3]
  41. Безопасность, IDS и VPN [212.4 + 212.5]
Урок 25. Apache и HTTPS [208.2]

Голый HTTP в 2026 году - это путь к плашке Not secure в браузере и отказу любого современного клиента. Задача администратора - научить Apache отдавать сайт по TLS: подключить ключ и сертификат, собрать корректную цепочку, разрешить только безопасные протоколы, развести несколько сайтов на одном IP через SNI и автоматически выпускать сертификаты через Let's Encrypt. В этом уроке разбираем mod_ssl от приватного ключа до certbot, с акцентом на то, что именно происходит при рукопожатии.

Изображение

Как это работает

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

Сертификат сервера почти никогда не подписан корневым CA напрямую. Между ними стоят промежуточные сертификаты. Чтобы клиент смог построить путь доверия от вашего сертификата до корня в своём хранилище, сервер обязан прислать всю цепочку промежуточных звеньев. Корень слать не нужно - он уже есть у клиента. Если промежуточное звено забыть, часть клиентов (особенно мобильные и curl без системных CA) выдадут ошибку доверия, хотя в браузере на десктопе всё может казаться рабочим.

Рукопожатие начинается с ClientHello, где клиент в расширении SNI открытым текстом сообщает имя хоста, к которому подключается. Это ключевой момент: до SNI один IP мог обслуживать только один HTTPS-сайт, потому что сервер не знал, какой сертификат показать, пока не расшифрует запрос - а расшифровать нельзя без правильного сертификата. SNI разрывает этот замкнутый круг: имя приходит до выбора сертификата, и Apache по нему выбирает нужный VirtualHost ещё до согласования ключей.

Протокол и набор шифров стороны выбирают в начале рукопожатия. Актуальны TLS 1.2 и TLS 1.3, всё что ниже - выключено и небезопасно. TLS 1.3 сам по себе использует только сильные шифронаборы, так что тонкая настройка ciphers касается в основном TLS 1.2. В Apache за это отвечают SSLProtocol и SSLCipherSuite.

Команды и примеры

Имена модуля и пакетов различаются. В Debian и Ubuntu сервис называется apache2, модуль включается через a2enmod. В RHEL и Fedora сервис httpd, mod_ssl ставится отдельным пакетом.

Код: Выделить всё

# Debian 13 / Ubuntu 24.04
apt install apache2
a2enmod ssl
a2ensite default-ssl
systemctl reload apache2

# RHEL 10 / Fedora 41+
dnf install httpd mod_ssl
systemctl enable --now httpd
Сгенерировать ключ и самоподписанный сертификат для теста (для прода берите Let's Encrypt, см. ниже):

Код: Выделить всё

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout /etc/ssl/private/site.key \
  -out /etc/ssl/certs/site.crt \
  -days 365 -subj "/CN=example.org"
Минимальный TLS-виртуалхост. Обратите внимание на отдельные директивы для сертификата, ключа и цепочки:

Код: Выделить всё

<VirtualHost *:443>
    ServerName example.org
    DocumentRoot /var/www/example

    SSLEngine on
    SSLCertificateFile      /etc/ssl/certs/site.crt
    SSLCertificateKeyFile   /etc/ssl/private/site.key
    SSLCertificateChainFile /etc/ssl/certs/intermediate.crt

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5:!3DES
    SSLHonorCipherOrder on
</VirtualHost>
Замечание по версиям: начиная с Apache 2.4.8 директива SSLCertificateChainFile считается устаревшей. Современный способ - положить сертификат сервера и цепочку в один PEM-файл и указать его в SSLCertificateFile. Для экзамена знайте обе формы; на новых стендах используйте объединённый файл.

SNI работает прозрачно: достаточно нескольких VirtualHost на *:443 с разными ServerName и своими сертификатами. Apache сам сопоставит имя из ClientHello с нужным блоком.

Перенаправление HTTP на HTTPS делается в отдельном виртуалхосте на 80 порту. Через mod_rewrite или, чище, через Redirect:

Код: Выделить всё

<VirtualHost *:80>
    ServerName example.org
    Redirect permanent / https://example.org/
</VirtualHost>
Выпуск боевого сертификата через Let's Encrypt. Certbot говорит с CA по протоколу ACME, подтверждает владение доменом (обычно HTTP-01 - файл в /.well-known/acme-challenge/) и сам правит конфиг Apache:

Код: Выделить всё

# Debian / Ubuntu
apt install certbot python3-certbot-apache
certbot --apache -d example.org -d www.example.org

# RHEL / Fedora
dnf install certbot python3-certbot-apache
certbot --apache -d example.org
Сертификаты Let's Encrypt живут 90 дней. Современный пакет ставит systemd-таймер certbot.timer, который сам обновляет их. Проверить:

Код: Выделить всё

systemctl list-timers certbot.timer
certbot renew --dry-run
Проверка результата снаружи - что именно отдаёт сервер и какая собирается цепочка:

Код: Выделить всё

openssl s_client -connect example.org:443 -servername example.org
apachectl configtest
Флаг -servername здесь обязателен: без него s_client не пошлёт SNI и вы можете попасть на дефолтный сайт вместо нужного.

Частые грабли
  • Забыта цепочка промежуточных сертификатов. В десктопном браузере всё зелёное, а curl, мобильные приложения и платёжные шлюзы ругаются на untrusted. Всегда проверяйте через openssl s_client с чистой машины.
  • Перепутаны местами ключ и сертификат в директивах, либо ключ не соответствует сертификату. Apache не стартует с key values mismatch. Сверьте модули: openssl x509 -noout -modulus -in cert и openssl rsa -noout -modulus -in key должны совпадать.
  • Listen 443 не объявлен или модуль ssl не включён - VirtualHost на 443 просто игнорируется, сайт открывается по 80.
  • NameVirtualHost и SNI: на старых конфигах люди до сих пор тащат директиву NameVirtualHost, в Apache 2.4 она удалена и вызывает предупреждение.
  • Слишком агрессивный SSLCipherSuite режет старые клиенты, слишком мягкий оставляет дыры. Не копируйте древние строки шифров из интернета - они часто включают уязвимые наборы.
  • Certbot не может пройти HTTP-01, потому что редирект 80 на 443 ловит и запрос на /.well-known/. Исключайте этот путь из редиректа либо используйте webroot-плагин.
  • Права на приватный ключ. Файл в /etc/ssl/private должен быть 0600 и принадлежать root, иначе либо утечка, либо Apache не сможет его прочитать.
Мини-лаба
  • Поднимите Apache (apache2 или httpd) и включите mod_ssl.
  • Сгенерируйте самоподписанный сертификат и ключ командой openssl req выше.
  • Опишите два VirtualHost на *:443 с разными ServerName (например a.test и b.test через /etc/hosts) и разными сертификатами.
  • Проверьте, что SNI работает: openssl s_client -connect 127.0.0.1:443 -servername a.test и -servername b.test должны вернуть разные CN.
  • Добавьте VirtualHost на *:80 с Redirect permanent на https.
  • Ограничьте SSLProtocol только TLSv1.2 и TLSv1.3, перезагрузите конфиг через apachectl configtest и reload.
  • По желанию: на публичном домене выпустите реальный сертификат через certbot --apache и прогоните certbot renew --dry-run.
Контрольные вопросы
  • Зачем сервер обязан отдавать промежуточные сертификаты и почему корневой слать не нужно?
  • Какое расширение TLS позволяет держать несколько HTTPS-сайтов на одном IP и в какой момент рукопожатия оно передаётся?
  • Чем SSLCertificateChainFile отличается от объединённого PEM в SSLCertificateFile и какой способ современный?
  • Как директивами Apache разрешить только TLS 1.2 и 1.3 и отключить всё остальное?
  • Какой плагин certbot правит конфиг Apache автоматически и как проверить обновление без реального перевыпуска?
  • Почему редирект всего трафика с 80 на 443 может сломать выпуск сертификата по HTTP-01?
👍2 ❤️2 🔥 😄 🤔
Аватара пользователя
cudawhale
Сообщения: 1
Зарегистрирован: 12 май 2026, 13:00

Re: Apache и HTTPS [208.2]

Сообщение cudawhale »

А обязательно делать отдельный VirtualHost на 80 для редиректа, или можно прямо в 443 как-то завернуть? У меня сейчас два почти одинаковых блока и это бесит.
👍1 ❤️ 🔥 😄 🤔1
Аватара пользователя
harddruid
Сообщения: 1
Зарегистрирован: 28 май 2026, 04:14

Re: Apache и HTTPS [208.2]

Сообщение harddruid »

Поймал грабли с certbot: редирект на https съедал .well-known и проверка падала. Помог webroot-плагин вместо --apache, оставил 80 порт живым только для challenge.
👍3 ❤️1 🔥 😄 🤔
Ответить
← Предыдущая глава
Веб-сервер Apache: базовая настройка [208.1]
Следующая глава →
Кэширующий прокси Squid [208.3]

Все главы курса «LPIC-2: инженер Linux (201 + 202)»

Поделиться темой: ✈ Telegram VK

Вернуться в «LPIC-2: инженер Linux»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость