Внедрение HSTS для всех поддоменов требует строгой последовательности действий: сначала обеспечьте HTTPS на каждом поддомене, затем настройте заголовок Strict-Transport-Security с директивой includeSubDomains, проверьте валидность сертификатов и убедитесь, что прокси не блокирует заголовок. Ошибка на любом этапе (например, HTTP на одном из поддоменов) заблокирует доступ ко всему домену.
Внедрение HSTS требует корректной конфигурации заголовка Strict-Transport-Security (Strict-Transport-Security) на уровне веб-сервера. Это обеспечивает принудительное использование
Заголовок Strict-Transport-Security сообщает браузеру, что все последующие запросы к домену должны идти только по протоколу HTTPS. Если сервер отправляет этот заголовок с HTTP-запроса, браузер его игнорирует. Это критично: при первой ошибке или перехвате трафика злоумышленник может подменить соединение на небезопасное.
Ключевая директива includeSubDomains должна включаться только после проверки всех поддоменов. Если mail.example.com работает по HTTP, а вы добавите includeSubDomains к главному домену, браузер заблокирует доступ ко всем ресурсам сайта, включая безопасные. Проверьте каждый поддомен на наличие валидного SSL/TLS сертификата и отсутствие ошибок перед включением этой опции.
Параметр max-age указывает время в секундах, в течение которого браузер будет запоминать правило HSTS. Рекомендуется установить значение не менее 31536000 (один год). Однако важно предусмотреть механизм перезагрузки правила при смене сертификата или обновлении конфигурации сервера. Иначе пользователи останутся без доступа к сайту до истечения срока действия заголовка.
Для добавления домена в список предзагрузки браузера (HSTS Preload List) необходимо пройти процедуру регистрации через Google HSTS Preload List. Это не обязательно для частных или новых сайтов, но повышает уровень защиты от атак на этапе первой загрузки страницы. Процесс требует соблюдения строгих критериев безопасности и подтверждения наличия заголовка на всех поддоменах.
Настройка прокси-серверов (Nginx, Apache) обязательна для корректной передачи заголовка. Прокси должен пересылать заголовок без изменений или ошибок. Если прокси удаляет или модифицирует Strict-Transport-Security, защита будет нарушена. Проверьте конфигурацию обратного прокси и убедитесь, что он не блокирует HTTPS-трафик.
Ошибки при настройке часто возникают из-за просроченных сертификатов на любом поддомене. Если сертификат истечет в течение периода max-age, цепочка безопасности нарушится, и браузер отклонит соединение. Мониторинг сроков действия сертификатов должен быть частью регулярных проверок инфраструктуры.
Использование HSTS не заменяет другие меры защиты, такие как защита от XSS или CSRF. Однако он существенно снижает риски атак типа Man-in-the-Middle, предотвращая перехват данных в процессе передачи. Внедрение заголовка должно сопровождаться тестированием на разных браузерах и устройствах для выявления скрытых проблем.
Настройка директивы includeSubDomains: проверка готовности поддоменов
Директива includeSubDomains в заголовке Strict-Transport-Security (HSTS) распространяет политику принудительного HTTPS на все поддомены вашего основного домена. Однако её включение без предварительной проверки состояния поддоменов создаёт критическую уязвимость: если хотя бы один из них работает по HTTP или имеет недействительный сертификат, браузер заблокирует доступ ко всем ресурсам домена, включая те, что работают корректно.
Перед добавлением флага includeSubDomains необходимо убедиться, что каждый поддомен (например, mail.example.com, api.example.com, shop.example.com) уже настроен на HTTPS и использует валидный SSL/TLS сертификат. Проверьте дату истечения сертификата: он должен действовать в течение всего периода max-age, указанного в заголовке HSTS. Просроченный сертификат на любом поддомене нарушит цепочку безопасности и приведет к сбросу настроек HSTS для всего домена.
Особое внимание уделите настройкам прокси-серверов (Nginx, Apache), если они используются перед веб-сервером. Прокси должен корректно перенаправлять HTTP-запросы на HTTPS и передавать заголовок HSTS без изменений или ошибок. Если прокси не настроен правильно, он может игнорировать заголовок или возвращать его с ошибкой, что сделает директиву includeSubDomains неработоспособной.
Используйте инструменты автоматической проверки, такие как onlinehstspreload.com или curl с флагом -I, чтобы убедиться, что поддомены возвращают заголовок Strict-Transport-Security с правильными параметрами. Тестируйте доступ к поддоменам из разных браузеров и на разных устройствах, так как некоторые браузеры могут по-разному обрабатывать ошибки сертификатов или отсутствие заголовка HSTS.
Если вы используете CDN (например, Cloudflare), убедитесь, что они также настроены на перенаправление HTTP в HTTPS и передают заголовок HSTS. Некоторые CDN имеют собственные механизмы управления HSTS, которые могут конфликтовать с настройками вашего веб-сервера. Проверьте документацию провайдера CDN для корректной интеграции.
После подтверждения готовности всех поддоменов добавьте директиву includeSubDomains в конфигурацию веб-сервера. Пример для Nginx:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
Для Apache используйте:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Не забудьте указать флаг always, чтобы заголовок отправлялся даже при ошибке 404 или 500, если это соответствует вашей политике безопасности. Однако помните, что если поддомен временно недоступен, браузер всё равно заблокирует доступ к основному домену до устранения проблемы.
Регулярно мониторьте статус всех поддоменов и сертификатов. Используйте мониторинг истечения сертификатов (например, через Certbot или Let's Encrypt) для автоматического продления. Если вы планируете использовать директиву preload, добавьте домен в список Google HSTS Preload List после того, как все поддомены будут стабильно работать по HTTPS в течение нескольких месяцев.
Использование директивы preload: возможности и ограничения
Директива preload позволяет браузеру запоминать ваш домен как безопасный еще до того, как пользователь посетит сайт. Это обеспечивает защиту сразу после первого запуска браузера, минуя этап ожидания заголовка Strict-Transport-Security с сервера. Однако этот механизм имеет строгие ограничения: он работает только для доменов, официально включенных в список Google HSTS Preload List.
Включение в preload-list возможно исключительно через специальную форму регистрации на сайте Google. Процесс требует подтверждения того, что ваш домен и все его поддомены стабильно работают по HTTPS с корректными сертификатами уже несколько месяцев. Для частных проектов, внутренних систем или новых сайтов этот шаг не обязателен и часто невыполним из-за бюрократических процедур проверки.
Если вы планируете использовать preload, убедитесь, что все поддомены (mail.example.com, api.example.com) настроены на HTTPS. Ошибка в одном из них приведет к отказу загрузки всего списка preload для всех пользователей. Также проверьте, что сертификаты не истекают в течение периода max-age, который вы указали ранее.
Для новых проектов или сайтов с ограниченным бюджетом настройка preload не требуется. Достаточно корректно настроить заголовок Strict-Transport-Security на веб-сервере (Nginx, Apache) и обеспечить автоматическое продление сертификатов. Этого достаточно для защиты от атак типа Man-in-the-Middle в большинстве случаев.
Использование preload оправдано только для крупных публичных сервисов с высокой нагрузкой, где критична мгновенная защита всех пользователей сразу после обновления браузера. Для остальных случаев стандартный заголовок с параметром max-age от года является достаточным решением.
Параметр max-age: сроки действия и управление безопасностью
Параметр max-age в заголовке Strict-Transport-Security указывает браузеру, сколько времени (в секундах) он должен запоминать, что сайт доступен только по защищенному протоколу HTTPS. Это значение определяет период, в течение которого браузер будет игнорировать попытки открыть сайт через HTTP и автоматически переключаться на безопасную версию. Рекомендуется устанавливать этот параметр не менее чем на 1 год (31536000 секунд), что обеспечивает долгосрочную защиту от атак типа Man-in-the-Middle даже при временных сбоях в работе веб-сервера или провайдера.
Однако установка максимального срока действия без возможности перезагрузки создает риски. Если сертификат безопасности истечет или будет скомпрометирован, браузер продолжит пытаться подключиться по HTTPS в течение всего указанного периода, даже если сервер уже не может его выдать. Это приведет к тому, что пользователи не смогут зайти на сайт до тех пор, пока не пройдет весь срок max-age или не будет вручную сброшен заголовок HSTS.
Чтобы избежать этой проблемы, необходимо предусмотреть механизм перезагрузки настроек безопасности. Самый надежный способ — использовать директиву includeSubDomains в сочетании с регулярным обновлением сертификатов и мониторингом их сроков действия. Если сертификат истекает раньше окончания периода max-age, сервер должен быть готов временно отключить заголовок HSTS или снизить его значение, чтобы пользователи могли получить доступ к ресурсу до момента замены сертификата.
На практике оптимальной стратегией является установка max-age на 1 год с возможностью динамического изменения этого значения. Например, при автоматическом продлении SSL-сертификата (через ACME-клиенты типа Certbot) можно программно обновлять значение max-age в конфигурации веб-сервера. Это позволяет поддерживать высокий уровень защиты без риска блокировки доступа к сайту на длительный срок.
Важно также учитывать, что параметр max-age применяется ко всем поддоменам, если включена директива includeSubDomains. Если один из поддоменов работает по HTTP или имеет просроченный сертификат, браузер заблокирует доступ ко всему домену. Поэтому перед установкой больших значений max-age необходимо убедиться, что все поддомены корректно настроены и имеют валидные сертификаты.
Для проверки текущего состояния HSTS можно использовать специальные инструменты, такие как onlinehsts.com или curl с флагом -I. Эти сервисы покажут значение max-age и подтвердят, что заголовок отправляется только с HTTPS-запросов. Регулярный мониторинг этих параметров поможет вовремя обнаружить ошибки в конфигурации и предотвратить блокировку доступа к сайту.
Ошибки при настройке HSTS: почему работает весь домен, если сломался один поддомен
Проблема блокировки всего домена из-за одного нерабочего поддомена возникает не из-за ошибки браузера, а из-за жесткой логики протокола безопасности. Если браузер получает заголовок Strict-Transport-Security с директивой includeSubDomains, он обязуется использовать HTTPS для всех запросов к этому домену и всем его поддоменам на протяжении указанного времени (max-age). Это обязательство действует независимо от того, работает конкретный поддомен или нет. Если один из поддоменов, например mail.example.com, не отвечает по HTTPS или возвращает ошибку соединения, браузер интерпретирует это как нарушение условий безопасности. В результате он блокирует доступ ко всем ресурсам домена example.com, включая те, которые работают корректно, пока проблема на проблемном поддомене не будет устранена.
Механизм блокировки работает следующим образом: при первом посещении сайта браузер проверяет наличие заголовка HSTS. Если он есть и содержит includeSubDomains, браузер запоминает правило для всего дерева доменов. При последующих запросах браузер игнорирует HTTP-версии всех поддоменов и пытается соединиться только по HTTPS. Если соединение с одним из поддоменов падает (например, сертификат просрочен или сервер не отвечает), браузер считает, что условие безопасности нарушено. Он сбрасывает кэш HSTS для всего домена и блокирует доступ до тех пор, пока пользователь не очистит куки и кэш или пока не пройдет период перезагрузки заголовка.
Чтобы избежать такой ситуации, необходимо строго контролировать состояние всех поддоменов перед включением директивы includeSubDomains. Если у вас есть поддомены mail.example.com, api.example.com и shop.example.com, все они должны быть доступны по HTTPS с валидными сертификатами. Если один из них временно недоступен или работает по HTTP, включать глобальную директиву для всех поддоменов нельзя. В таких случаях рекомендуется либо временно отключить includeSubDomains, настроив HSTS только для основного домена, либо исправить проблему на проблемном поддомене перед активацией глобальной защиты.
Проверка работоспособности каждого поддомена должна быть частью регулярного мониторинга. Используйте инструменты вроде onlinehsts.com или curl с флагом -I для проверки заголовков на всех поддоменах. Убедитесь, что сертификаты не истекают в течение периода max-age. Если вы используете CDN или прокси (Nginx, Apache), проверьте их конфигурацию: они должны корректно передавать заголовок HSTS и обеспечивать HTTPS-соединение для всех поддоменов. Ошибки в настройке прокси могут привести к тому, что браузер получит некорректный ответ или отсутствие заголовка, что также нарушит условия безопасности.
Практический пример: у вас есть сайт с основным доменом example.com и поддоменами blog.example.com и forum.example.com. Вы настроили HSTS с includeSubDomains на год. Поддомен forum.example.com временно недоступен из-за обновления сервера. Пользователь пытается зайти на main.example.com — браузер блокирует доступ, так как ожидает, что все поддомены работают по HTTPS. Чтобы восстановить доступ, нужно либо исправить проблему на forum.example.com, либо удалить заголовок HSTS с основного домена и настроить его только для example.com без includeSubDomains, пока проблема не будет решена.
Если вы используете автоматическое обновление сертификатов через Let's Encrypt или аналогичные сервисы, убедитесь, что процесс обновления работает для всех поддоменов. Просроченный сертификат на любом из них приведет к нарушению цепочки безопасности и блокировке всего домена. Настройте уведомления об истечении срока действия сертификатов заранее, чтобы успеть их продлить до окончания периода max-age. Также проверьте, что прокси-серверы не отбрасывают заголовки HSTS при перенаправлении запросов между поддоменами.
В случае если блокировка уже произошла и доступ к сайту потерян, единственный способ восстановить работу — очистить кэш HSTS в браузере. В Chrome это можно сделать через флаги (chrome://net-internals/#hsts), удалив домен из списка preload. Также поможет удаление куки и использование режима инкогнито для проверки доступа. Однако это временное решение; без устранения проблемы на проблемном поддомене блокировка повторится при следующем обновлении страницы или перезагрузке браузера.
Для предотвращения подобных ситуаций в будущем рекомендуется внедрить систему мониторинга доступности всех поддоменов по HTTPS. Используйте инструменты вроде Uptime Robot или Pingdom для отслеживания состояния каждого поддомена. Настройте алерты на случай падения доступности или истечения срока действия сертификатов. Это позволит устранить проблемы до того, как они повлияют на работу всего домена и заблокируют доступ пользователям.
Если вы планируете использовать директиву preload в будущем, помните, что она требует регистрации домена в списке Google HSTS Preload List. Добавление туда возможно только после успешного прохождения всех проверок безопасности, включая корректную работу всех поддоменов. Ошибки на любом из них приведут к отказу в добавлении домена в список preload. Поэтому перед подачей заявки убедитесь, что все поддомены работают стабильно по HTTPS с валидными сертификатами и заголовками HSTS настроены корректно.
Итоговая рекомендация: включайте директиву includeSubDomains только после тщательной проверки всех поддоменов. Убедитесь, что они доступны по HTTPS с валидными сертификатами и без ошибок в конфигурации прокси. Регулярно мониторьте состояние всех поддоменов и своевременно обновляйте сертификаты. Если один из поддоменов временно недоступен, отключите includeSubDomains до его восстановления. Это обеспечит стабильную работу сайта и предотвратит блокировку доступа пользователей к основным ресурсам.
Проверка валидности SSL/TLS сертификатов для всех поддоменов
Настройка HSTS с директивой includeSubDomains требует абсолютной целостности цепочки шифрования. Если на любом из ваших поддоменов (например, mail.example.com или api.example.com) сертификат просрочен, недействителен или выдан ненадежным авторитетом, браузер заблокирует доступ ко всему домену-родителю. Это происходит потому, что HSTS принудительно перекидывает пользователя на HTTPS, и если соединение там невозможно из-за проблем с сертификатом, пользователь теряет доступ к ресурсам даже тех поддоменов, где всё работает исправно.
Перед включением директивы includeSubDomains необходимо провести аудит всех ресурсов. Убедитесь, что каждый поддомен имеет свой собственный валидный сертификат или входит в состав доверенного wildcard-сертификата (если используется). Проверьте даты действия сертификатов: они должны покрывать весь период max-age, который вы указали в заголовке HSTS. Если вы установите max-age на 1 год, но сертификат истечет через полгода, браузеры запомнят этот домен как небезопасный и будут блокировать его до ручного сброса настроек безопасности.
Используйте инструменты автоматической проверки, такие как SSL Labs или встроенные утилиты командной строки (openssl s_client), чтобы убедиться в отсутствии ошибок при подключении. Особое внимание уделите поддоменам, которые могут быть временно недоступны для обслуживания: если вы планируете обновить сертификат на одном из них, убедитесь, что новый сертификат уже установлен и проверен до того, как старый истечет. Никогда не оставляйте промежуток времени без валидного сертификата на критически важных поддоменах.
Практический пример: у вас есть основной сайт example.com и поддомен blog.example.com. Вы настроили HSTS с includeSubDomains и max-age=31536000. Через 8 месяцев вы забыли продлить сертификат для blog.example.com. Пользователь, зашедший на main.example.com, получает ошибку безопасности, так как браузер проверяет цепочку шифрования при каждом запросе. Даже если основной сайт работает, доступ к нему блокируется из-за проблемы с поддоменом.
Решение заключается в строгом мониторинге сроков действия сертификатов. Настройте уведомления за 30–60 дней до истечения срока. Используйте автоматизированные системы обновления сертификатов (например, Let's Encrypt через Certbot), которые позволяют продлевать их без простоя. Если вы используете прокси-серверы (Nginx, Apache), убедитесь, что они корректно передают заголовки и не блокируют соединения из-за внутренних ошибок конфигурации. Регулярная проверка всех поддоменов — обязательное условие для стабильной работы HSTS.
Заголовок HSTS должен отправляться только с HTTPS-запросов
Заголовок Strict-Transport-Security (HSTS) является критически важным элементом защиты от атак типа Man-in-the-Middle. Его главная особенность заключается в том, что браузеры игнорируют этот заголовок, если он передан по незашифрованному соединению HTTP. Это означает, что попытка настроить HSTS на порту 80 не только бесполезна, но и может привести к сбросу ранее установленных настроек безопасности.
При первом обращении к сайту браузер всегда пытается установить безопасное соединение. Если сервер возвращает заголовок HSTS в ответе на HTTP-запрос, браузер отбрасывает его. Более того, некоторые реализации могут интерпретировать это как сигнал о том, что сайт небезопасен, и сбрасывать куки или другие настройки безопасности, связанные с этим доменом.
Корректный алгоритм работы выглядит следующим образом: клиент отправляет запрос по HTTP (если HTTPS еще не установлен), сервер должен вернуть ответ 301 или 302 с перенаправлением на HTTPS и заголовком HSTS. Только после успешного перехода на защищенный порт браузер начнет принимать и исполнять директивы этого заголовка.
Ошибка возникает, когда администратор пытается включить HSTS сразу для всех запросов, включая HTTP, либо когда прокси-сервер случайно передает заголовок в ответе на незашифрованное соединение. В таких случаях политика безопасности не применяется, а домен остается уязвимым для перехвата трафика.
Для проверки корректности настройки используйте инструменты типа curl или онлайн-чекеры HSTS. Запрос вида 'curl -I http://example.com' должен показать отсутствие заголовка Strict-Transport-Security в ответе на HTTP и его наличие только в ответе на HTTPS. Это гарантирует, что браузер будет принудительно использовать защищенный канал связи при последующих визитах.
Проверка конфигурации прокси-сервера для корректной передачи заголовка HSTS
Настройка веб-сервера (Nginx, Apache) или обратного прокси часто становится критическим узлом при внедрении HSTS. Если прокси не настроен правильно, он может игнорировать заголовок Strict-Transport-Security, удалять его перед отправкой клиенту или возвращать ошибку, что приведет к сбросу защиты всего домена и поддоменов.
В конфигурации Nginx необходимо убедиться, что директива `add_header` присутствует в блоке сервера или локации, отвечающих за HTTPS. Важно не добавлять этот заголовок с условием `if`, так как это может привести к его отправке при первом запросе по HTTP, что браузеры интерпретируют как ошибку и игнорируют инструкцию. Правильный подход — жесткое добавление заголовка только в ответ на HTTPS-запрос.
Пример корректной конфигурации для Nginx выглядит следующим образом: внутри блока `server` с параметром `listen 443 ssl`, следует указать `add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;`. Параметр `always` гарантирует, что заголовок будет добавлен даже при ошибках обработки запроса (например, 500 или 403), если это не нарушает логику безопасности вашего приложения.
Для Apache аналогичная настройка реализуется через директиву `Header always set`. Ключевое слово `always` здесь также необходимо, чтобы заголовок передавался независимо от статуса ответа. Убедитесь, что модуль `mod_headers` активирован и нет правил в `.htaccess`, которые могли бы перезаписывать или удалять этот заголовок.
При работе с балансировщиками нагрузки (например, HAProxy, Cloudflare) важно проверить их настройки прокси. Некоторые облачные прокси по умолчанию могут не пересылать HSTS-заголовки от бэкенд-сервера клиенту без явного включения опции. В случае использования CDN необходимо убедиться, что в настройках безопасности включена передача заголовков безопасности и установлен корректный срок действия (max-age), который может отличаться от настроек вашего внутреннего сервера.
Особое внимание уделите поддоменам. Если основной домен настроен верно, но прокси для поддомена (например, mail.example.com) работает через отдельный виртуальный хост или контейнер с другой конфигурацией, заголовок может отсутствовать именно там. Это приведет к тому, что браузер заблокирует весь сайт, включая корректно работающие разделы, так как политика HSTS применяется ко всему домену.
После внесения изменений в конфигурационные файлы прокси или веб-сервера обязательно перезагрузите службы и проверьте результат. Используйте команду `curl -I https://example.com` для проверки наличия заголовка в ответе на защищенный запрос. Запрос по HTTP (`curl -I http://example.com`) должен возвращать ошибку 301 (перенаправление) с заголовком Location, указывающим на HTTPS версию сайта, и не содержать Strict-Transport-Security в теле ответа HTTP.
Если вы используете автоматическое обновление сертификатов (например, через Certbot), убедитесь, что скрипт перезапускает веб-сервер после установки новых ключей. Без перезагрузки новые настройки прокси или обновленные сертификаты могут не примениться, и старый заголовок с истекшим сроком действия продолжит работать до момента его естественного окончания.
Вопросы и ответы
Что произойдет с доступом к сайту, если один из поддоменов не настроен на HTTPS?
Браузер заблокирует доступ ко всем ресурсам домена (включая корректно работающие поддомены) на весь срок действия заголовка HSTS. Пользователь увидит ошибку безопасности при попытке перехода по ссылке.
Можно ли использовать директиву preload для собственного домена?
Нет, добавление в список preload возможно только через официальную программу Google HSTS Preload List. Для частных или новых сайтов этот шаг не обязателен и технически недоступен.
Как часто нужно проверять сертификаты поддоменов?
Проверку следует проводить регулярно, но критически важно убедиться, что ни один сертификат не истекает в течение периода max-age. Просроченный сертификат на любом поддомене нарушит цепочку безопасности и заблокирует доступ ко всему домену.
Почему заголовок HSTS нельзя отправлять с HTTP-запроса?
Браузеры игнорируют заголовок Strict-Transport-Security, если он передан по незашифрованному соединению. Попытка настроить его на порту 80 бесполезна и может привести к сбросу ранее установленных настроек безопасности.
server {
listen 443 ssl;
server_name example.com www.example.com mail.example.com api.example.com;
# Настройка HSTS с включением поддоменов
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Пример конфигурации SSL
ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;
location / {
root /var/www/html;
index index.html;
}
}
# Важно: убедитесь, что mail.example.com и api.example.com также имеют свои конфиги с SSL и HSTS
server {
listen 80;
server_name mail.example.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name mail.example.com;
ssl_certificate /etc/ssl/certs/mail.example.com.crt;
ssl_certificate_key /etc/ssl/private/mail.example.com.key;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
}VirtualHost *:443 {
ServerName example.com
ServerAlias www.example.com mail.example.com api.example.com
# Настройка HSTS с включением поддоменов
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Пример конфигурации SSL
SSLEngine on
SSLCertificateFile /etc/ssl/certs/example.com.crt
SSLCertificateKeyFile /etc/ssl/private/example.com.key
DocumentRoot /var/www/html
}
# Важно: убедитесь, что mail.example.com и api.example.com также имеют свои VirtualHost с SSL и HSTS
VirtualHost *:80 {
ServerName mail.example.com
Redirect permanent / https://mail.example.com/
}
VirtualHost *:443 {
ServerName mail.example.com
SSLEngine on
SSLCertificateFile /etc/ssl/certs/mail.example.com.crt
SSLCertificateKeyFile /etc/ssl/private/mail.example.com.key
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
}# Проверка валидности сертификата для поддомена
openssl s_client -connect mail.example.com:443 -servername mail.example.com 2>/dev/null | openssl x509 -noout -dates
# Ожидаемый вывод:
# notBefore=Jan 1 00:00:00 2024 GMT
# notAfter=Jan 1 00:00:00 2025 GMT# Пример корректной конфигурации для Nginx
server {
listen 443 ssl;
server_name example.com www.example.com api.example.com;
# Обязательное добавление заголовка только на HTTPS
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
# Пример сжатия и других настроек
gzip on;
location / {
try_files $uri $uri/ =404;
}
}
# Важно: НЕ добавляйте add_header внутри блока if или location без условий,
# если это может привести к отправке заголовка на HTTP запросе.
# Пример неправильной конфигурации (закомментирован):
# server {
# listen 80;
# server_name example.com;
#
# # ОШИБКА: добавление HSTS на HTTP запросе приведет к игнорированию браузером
# add_header Strict-Transport-Security "max-age=31536000" always;
# }# Пример конфигурации для Apache (mod_headers)
<VirtualHost *:443>
ServerName example.com
# Модуль mod_headers должен быть загружен: LoadModule headers_module modules/mod_headers.so
# Установка заголовка с флагом always
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
# Включение SSL
SSLEngine on
SSLCertificateFile /path/to/cert.pem
SSLCertificateKeyFile /path/to/key.pem
</VirtualHost>
# Проверка наличия модуля:
# a2enmod headers
