На этой странице представлены инструкции по настройке HTTPS на ваших серверах, включая следующие шаги:
- Создание 2048-битной пары открытого/закрытого ключей RSA.
- Создание запроса на подпись сертификата (CSR), который внедряет ваш открытый ключ.
- Передача CSR в центр сертификации (CA) для получения окончательного сертификата или цепочки сертификатов.
- Установка окончательного сертификата в недоступном через Интернет месте, например
/etc/ssl(Linux и Unix) или там, где этого требует IIS (Windows).
Генерация ключей и запросов на подпись сертификата
В этом разделе используется программа командной строки openssl, которая поставляется с большинством систем Linux, BSD и Mac OS X, для генерации закрытых и открытых ключей, а также CSR.
Создайте пару открытого/закрытого ключей.
Для начала сгенерируйте пару ключей RSA длиной 2048 бит. Более короткий ключ можно взломать с помощью перебора, а более длинные ключи используют ненужные ресурсы.
Используйте следующую команду для создания пары ключей RSA:
openssl genrsa -out www.example.com.key 2048
Это дает следующий результат:
Generating RSA private key, 2048 bit long modulus
.+++
.......................................................................................+++
e is 65537 (0x10001)
Создать запрос на подпись сертификата
На этом этапе вы встраиваете свой открытый ключ и информацию о своей организации и своем веб-сайте в запрос на подпись сертификата или CSR. Команда openssl запрашивает необходимые метаданные.
Выполнение следующей команды:
openssl req -new -sha256 -key www.example.com.key -out www.example.com.csr
Выводит следующее:
You are about to be asked to enter information that will be incorporated
into your certificate request
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:California
Locality Name (for example, city) []:Mountain View
Organization Name (for example, company) [Internet Widgits Pty Ltd]:Example, Inc.
Organizational Unit Name (for example, section) []:Webmaster Help Center Example
Team
Common Name (e.g. server FQDN or YOUR name) []:www.example.com
Email Address []:webmaster@example.com
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Чтобы убедиться в достоверности CSR, выполните следующую команду:
openssl req -text -in www.example.com.csr -noout
Ответ должен выглядеть следующим образом:
Certificate Request:
Data:
Version: 0 (0x0)
Subject: C=CA, ST=California, L=Mountain View, O=Google, Inc.,
OU=Webmaster Help Center Example Team,
CN=www.example.com/emailAddress=webmaster@example.com
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
00:ad:fc:58:e0:da:f2:0b:73:51:93:29:a5:d3:9e:
f8:f1:14:13:64:cc:e0:bc:be:26:5d:04:e1:58:dc:
...
Exponent: 65537 (0x10001)
Attributes:
a0:00
Signature Algorithm: sha256WithRSAEncryption
5f:05:f3:71:d5:f7:b7:b6:dc:17:cc:88:03:b8:87:29:f6:87:
2f:7f:00:49:08:0a:20:41:0b:70:03:04:7d:94:af:69:3d:f4:
...
Отправьте CSR в центр сертификации
Различные центры сертификации (ЦС) требуют, чтобы вы отправляли им свои CSR разными способами. Это может включать использование формы на их веб-сайте или отправку CSR по электронной почте. Некоторые центры сертификации или их реселлеры могут даже автоматизировать некоторые или все процессы, включая, в некоторых случаях, пару ключей и генерацию CSR.
Отправьте CSR в свой центр сертификации и следуйте его инструкциям, чтобы получить окончательный сертификат или цепочку сертификатов.
Разные центры сертификации взимают разные суммы денег за услугу подтверждения вашего открытого ключа.
Существуют также варианты сопоставления вашего ключа с несколькими DNS-именами, включая несколько отдельных имен (например, все example.com, www.example.com, example.net и www.example.net) или имена с «подстановочными знаками», такие как как *.example.com .
Скопируйте сертификаты на все ваши интерфейсные серверы в недоступном через Интернет месте, например /etc/ssl (Linux и Unix) или там, где их требует IIS (Windows).
Включите HTTPS на ваших серверах
Включение HTTPS на ваших серверах является важным шагом в обеспечении безопасности ваших веб-страниц.
- Используйте инструмент настройки сервера Mozilla, чтобы настроить свой сервер для поддержки HTTPS.
- Регулярно тестируйте свой сайт с помощью теста SSL-сервера Qualys и убедитесь, что вы получили как минимум A или A+.
На этом этапе вы должны принять важное операционное решение. Выберите один из следующих вариантов:
- Выделите отдельный IP-адрес для каждого имени хоста, с которого ваш веб-сервер обслуживает контент.
- Используйте виртуальный хостинг на основе имени.
Если вы используете разные IP-адреса для каждого имени хоста, вы можете поддерживать как HTTP, так и HTTPS для всех клиентов. Однако большинство операторов сайтов используют виртуальный хостинг на основе имен для экономии IP-адресов и в целом потому, что это более удобно.
Если на ваших серверах еще нет службы HTTPS, включите ее сейчас (без перенаправления HTTP на HTTPS. Дополнительные сведения см. в разделе «Перенаправление HTTP на HTTPS »). Настройте свой веб-сервер для использования купленных и установленных сертификатов. Вам может пригодиться генератор конфигурации Mozilla .
Если у вас много имен хостов или поддоменов, каждый из них должен использовать правильный сертификат.
Теперь и регулярно на протяжении всего существования вашего сайта проверяйте конфигурацию HTTPS с помощью теста SSL-сервера Qualys . Ваш сайт должен получить оценку A или A+. Считайте все, что приводит к снижению оценки, ошибкой, и будьте внимательны, поскольку постоянно разрабатываются новые атаки на алгоритмы и протоколы.
Сделайте внутрисайтовые URL-адреса относительными
Теперь, когда вы обслуживаете свой сайт как по HTTP, так и по HTTPS, все должно работать максимально гладко, независимо от протокола. Важным фактором является использование относительных URL-адресов для внутрисайтовых ссылок.
Убедитесь, что внутрисайтовые и внешние URL-адреса не зависят от определенного протокола. Используйте относительные пути или оставьте протокол, как в //example.com/something.js .
Обслуживание страницы, содержащей HTTP-ресурсы, с использованием HTTPS может вызвать проблемы . Когда браузер обнаруживает защищенную в других отношениях страницу, использующую незащищенные ресурсы, он предупреждает пользователей о том, что страница не является полностью безопасной, а некоторые браузеры отказываются загружать или выполнять ресурсы HTTP, что нарушает работу страницы. Однако вы можете безопасно включать ресурсы HTTPS на страницу HTTP. Дополнительные рекомендации по устранению этих проблем см. в разделе Исправление смешанного контента .
Переход по ссылкам на основе HTTP на другие страницы вашего сайта также может снизить удобство использования с HTTPS на HTTP. Чтобы исправить это, сделайте ваши внутрисайтовые URL-адреса как можно более относительными, сделав их либо относительными к протоколу (без протокола, начиная с //example.com ), либо относительно хоста (начиная только с пути, например /jquery.js ). .
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="//example.com/jquery.js"></script> <link rel="stylesheet" href="//assets.example.com/style.css"/> <img src="//img.example.com/logo.png"/>; <p>A <a href="//example.com/2014/12/24/">new post on cats!</a></p>
<h1>Welcome To Example.com</h1> <script src="/jquery.js"></script> <link rel="stylesheet" href="/assets/style.css"/> <img src="/images/logo.png"/>; <p>A <a href="/2014/12/24">new post on cats!</a></p> <p>Check out this <a href="https://foo.com/"><b>other cool site.</b></a></p>
Обновляйте ссылки скриптом, а не вручную, чтобы не допускать ошибок. Если содержимое вашего сайта находится в базе данных, протестируйте свой сценарий на рабочей копии базы данных. Если содержимое вашего сайта состоит только из простых файлов, протестируйте свой сценарий на рабочей копии файлов. Вносите изменения в рабочую среду только после того, как изменения пройдут контроль качества, как обычно. Вы можете использовать сценарий Брэма ван Дамма или что-то подобное, чтобы обнаружить смешанный контент на вашем сайте.
При создании ссылок на другие сайты (в отличие от включения ресурсов с них) не меняйте протокол. Вы не можете контролировать работу этих сайтов.
Чтобы сделать миграцию более плавной для крупных сайтов, мы рекомендуем использовать URL-адреса, относящиеся к протоколу. Если вы еще не уверены, сможете ли вы полностью развернуть HTTPS, принудительное использование HTTPS на вашем сайте для всех подресурсов может иметь неприятные последствия. Вероятно, наступит период времени, когда HTTPS будет для вас новым и странным, а HTTP-сайт по-прежнему будет работать так же хорошо, как и прежде. Со временем вы завершите миграцию и заблокируете HTTPS (см. следующие два раздела).
Если ваш сайт зависит от скриптов, изображений или других ресурсов, предоставляемых третьей стороной, например CDN или jquery.com, у вас есть два варианта:
- Используйте для этих ресурсов URL-адреса, относящиеся к протоколу. Если третья сторона не поддерживает HTTPS, попросите ее об этом. Большинство из них уже это делают, включая jquery.com.
- Обслуживайте ресурсы с сервера, которым вы управляете, который предлагает как HTTP, так и HTTPS. В любом случае это зачастую хорошая идея, потому что тогда вы сможете лучше контролировать внешний вид, производительность и безопасность вашего сайта, и вам не придется доверять третьей стороне обеспечение безопасности вашего сайта.
Перенаправить HTTP на HTTPS
Чтобы указать поисковым системам использовать HTTPS для доступа к вашему сайту, поместите каноническую ссылку в начале каждой страницы, используя теги <link rel="canonical" href="https://…"/> .
Включите строгую транспортную безопасность и защитите файлы cookie.
На этом этапе вы готовы «заблокировать» использование HTTPS:
- Используйте строгую транспортную безопасность HTTP (HSTS), чтобы избежать затрат на перенаправление 301.
- Всегда устанавливайте флажок «Безопасно» для файлов cookie.
Во-первых, используйте Strict Transport Security, чтобы сообщить клиентам, что им следует всегда подключаться к вашему серверу по протоколу HTTPS, даже если они следуют ссылке http:// . Это предотвращает такие атаки, как удаление SSL , и позволяет избежать затрат на 301 redirect , которое мы включили в разделе «Перенаправление HTTP на HTTPS» .
Чтобы включить HSTS, установите заголовок Strict-Transport-Security . На странице HSTS OWASP есть ссылки на инструкции для различных типов серверного программного обеспечения.
Большинство веб-серверов предлагают аналогичную возможность добавления пользовательских заголовков.
Также важно убедиться, что клиенты никогда не отправляют файлы cookie (например, для аутентификации или настроек сайта) через HTTP. Например, если файл cookie аутентификации пользователя будет представлен в виде обычного текста, ваша гарантия безопасности для всего его сеанса будет уничтожена, даже если вы все сделали правильно!
Чтобы избежать этого, измените свое веб-приложение, чтобы оно всегда устанавливало флаг безопасности для файлов cookie, которые оно устанавливает. На этой странице OWASP объясняется, как установить флаг безопасности в некоторых платформах приложений. В каждой прикладной платформе есть способ установить флаг.
Большинство веб-серверов предлагают простую функцию перенаправления. Используйте 301 (Moved Permanently) чтобы указать поисковым системам и браузерам, что версия HTTPS является канонической, и перенаправлять пользователей на HTTPS-версию вашего сайта с HTTP.
Рейтинг поиска
Google использует HTTPS как положительный индикатор качества поиска . Google также публикует руководство о том, как перенести, переместить или перенести ваш сайт , сохранив при этом его рейтинг в поиске. Bing также публикует рекомендации для веб-мастеров .
Производительность
Когда уровни контента и приложения хорошо настроены (обратитесь к книгам Стива Соудерса за советом), оставшиеся проблемы с производительностью TLS обычно невелики по сравнению с общей стоимостью приложения. Вы также можете уменьшить и амортизировать эти затраты. Советы по оптимизации TLS см. в статьях «Высокопроизводительная браузерная сеть» Ильи Григорика, а также в «Поваренной книге OpenSSL» Ивана Ристича и Bulletproof SSL And TLS .
В некоторых случаях TLS может повысить производительность, в основном благодаря возможности HTTP/2. Для получения дополнительной информации обратитесь к выступлению Криса Палмера о производительности HTTPS и HTTP/2 на Chrome Dev Summit 2014 .
Заголовки реферера
Когда пользователи переходят по ссылкам с вашего HTTPS-сайта на другие HTTP-сайты, пользовательские агенты не отправляют заголовок Referer. Если это проблема, есть несколько способов ее решения:
- Остальные сайты должны перейти на HTTPS. Если реферальные сайты выполнили раздел «Включение HTTPS на ваших серверах» данного руководства, вы можете изменить ссылки на своем сайте на их с
http://наhttps://или использовать ссылки, относящиеся к протоколу. - Чтобы обойти различные проблемы с заголовками Referer, используйте новый стандарт Referrer Policy .
Доход от рекламы
Операторы сайтов, монетизирующие свой сайт путем показа рекламы, хотят быть уверены, что переход на HTTPS не приведет к снижению количества показов рекламы. Однако из-за проблем безопасности смешанного контента HTTP <iframe> не работает на странице HTTPS. Пока рекламодатели не будут публиковать контент через HTTPS, операторы сайтов не смогут перейти на HTTPS без потери дохода от рекламы; но до тех пор, пока операторы сайтов не перейдут на HTTPS, у рекламодателей мало мотивации публиковать HTTPS.
Вы можете начать процесс выхода из этой тупиковой ситуации, используя рекламодателей, предлагающих рекламные услуги через HTTPS, и попросив рекламодателей, которые вообще не обслуживают HTTPS, хотя бы сделать это опцией. Возможно, вам придется отложить выполнение задачи «Сделать URL-адреса внутри сайта относительными» до тех пор, пока достаточное количество рекламодателей не начнут правильно взаимодействовать.