Что такое https как настроить https сервер

Настройка HTTPS-серверов

Чтобы настроить HTTPS-сервер, необходимо включить параметр ssl на слушающих сокетах в блоке server, а также указать местоположение файлов с сертификатом сервера и секретным ключом:

Сертификат сервера является публичным. Он посылается каждому клиенту, соединяющемуся с сервером. Секретный ключ следует хранить в файле с ограниченным доступом (права доступа должны позволять главному процессу nginx читать этот файл). Секретный ключ можно также хранить в одном файле с сертификатом:

при этом права доступа к файлу следует также ограничить. Несмотря на то, что и сертификат, и ключ хранятся в одном файле, клиенту посылается только сертификат.

С помощью директив ssl_protocols и ssl_ciphers можно ограничить соединения использованием только “сильных” версий и шифров SSL/TLS. По умолчанию nginx использует “ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ” и “ ssl_ciphers HIGH:!aNULL:!MD5 ”, поэтому их явная настройка в общем случае не требуется. Следует отметить, что значения по умолчанию этих директив несколько раз менялись.

Оптимизация HTTPS-сервера

SSL-операции потребляют дополнительные ресурсы процессора. На мультипроцессорных системах следует запускать несколько рабочих процессов, не меньше числа доступных процессорных ядер. Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках которой формируются криптографические параметры сессии. Существует два способа уменьшения числа этих операций, производимых для каждого клиента: использование постоянных (keepalive) соединений, позволяющих в рамках одного соединения обрабатывать сразу несколько запросов, и повторное использование параметров SSL-сессии для предотвращения необходимости выполнения SSL handshake для параллельных и последующих соединений. Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и настраиваемом директивой ssl_session_cache. В 1 мегабайт кэша помещается около 4000 сессий. Таймаут кэша по умолчанию равен 5 минутам. Он может быть увеличен с помощью директивы ssl_session_timeout. Вот пример конфигурации, оптимизированной под многоядерную систему с 10-мегабайтным разделяемым кэшем сессий:

Цепочки SSL-сертификатов

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

Полученный файл следует указать в директиве ssl_certificate:

Если сертификат сервера и связка сертификатов были соединены в неправильном порядке, nginx откажется запускаться и выдаст сообщение об ошибке:

поскольку nginx попытается использовать секретный ключ с первым сертификатом из связки вместо сертификата сервера.

Браузеры обычно сохраняют полученные промежуточные сертификаты, подписанные доверенными центрами сертификации, поэтому активно используемые браузеры уже могут иметь требуемые промежуточные сертификаты и не выдать предупреждение о сертификате, присланном без связанной с ним цепочки сертификатов. Убедиться в том, что сервер присылает полную цепочку сертификатов, можно при помощи утилиты командной строки openssl , например:

При тестировании конфигураций с SNI необходимо указывать опцию -servername , так как openssl по умолчанию не использует SNI.

В этом примере субъект (“s”) сертификата №0 сервера www.GoDaddy.com подписан издателем (“i”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем ValiCert, Inc., чей сертификат хранится во встроенной в браузеры базе данных сертификатов (которая в тёмном чулане хранится в доме, который построил Джек).

Если связку сертификатов не добавили, будет показан только сертификат сервера №0.

Единый HTTP/HTTPS сервер

Можно настроить единый сервер, который обслуживает как HTTP-, так и HTTPS-запросы:

До версии 0.7.14 SSL нельзя было включить выборочно для отдельных слущающих сокетов, как показано выше. SSL можно было включить только для всего сервера целиком, с помощью директивы ssl, что не позволяло настроить единый HTTP/HTTPS сервер. Для решения этой задачи был добавлен параметр ssl директивы listen. Поэтому использование директивы ssl в современных версиях не рекомендуется.

Выбор HTTPS-сервера по имени

Типичная проблема возникает при настройке двух и более серверов HTTPS, слушающих на одном и том же IP-адресе:

В такой конфигурации браузер получит сертификат сервера по умолчанию, т.е. www.example.com , независимо от запрашиваемого имени сервера. Это связано с поведением протокола SSL. SSL-соединение устанавливается до того, как браузер посылает HTTP-запрос, и nginx не знает имени запрашиваемого сервера. Следовательно, он лишь может предложить сертификат сервера по умолчанию.

Наиболее старым и надёжным способом решения этой проблемы является назначение каждому HTTPS-серверу своего IP-адреса:

SSL-сертификат с несколькими именами

Существуют и другие способы, которые позволяют использовать один и тот же IP-адрес сразу для нескольких HTTPS-серверов. Все они, однако, имеют свои недостатки. Одним из таких способов является использование сертификата с несколькими именами в поле SubjectAltName сертификата, например www.example.com и www.example.org . Однако, длина поля SubjectAltName ограничена.

Другим способом является использование wildcard-сертификата, например *.example.org . Такой сертификат защищает все поддомены указанного домена, но только на заданном уровне. Под такой сертификат подходит www.example.org , но не подходят example.org и www.sub.example.org . Два вышеуказанных способа можно комбинировать. Сертификат может одновременно содержать и точное, и wildcard имена в поле SubjectAltName, например example.org и *.example.org .

Лучше поместить сведения о файле сертификата с несколькими именами и файле с его секретным ключом на уровне конфигурации http, чтобы все серверы унаследовали их единственную копию в памяти:

Указание имени сервера

Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе — расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Сейчас SNI поддерживается большинством современных браузеров, однако может не использоваться некоторыми старыми или специализированными клиентами.

В SNI можно передавать только доменные имена, однако некоторые браузеры могут ошибочно передавать IP-адрес сервера в качестве его имени, если в запросе указан IP-адрес. Полагаться на это не следует.

Чтобы использовать SNI в nginx, соответствующая поддержка должна присутствовать как в библиотеке OpenSSL, использованной при сборке бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы. OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была собрана с опцией конфигурации Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом “-V” об этом сообщается:

Однако если nginx, собранный с поддержкой SNI, в процессе работы подгружает библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение:

Совместимость

• Статус поддержки SNI отображается по ключу “-V” начиная с версий 0.8.21 и 0.7.62.
• Параметр ssl директивы listen поддерживается начиная с версии 0.7.14. До версии 0.8.21 его можно было указывать только совместно с параметром default .
• SNI поддерживается начиная с версии 0.5.23.
• Разделяемый кэш SSL-сессий поддерживается начиная с версии 0.5.6.

• Версия 1.9.1 и более поздние: протоколами SSL по умолчанию являются TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
• Версия 0.7.65, 0.8.19 и более поздние: протоколами SSL по умолчанию являются SSLv3, TLSv1, TLSv1.1 и TLSv1.2 (если поддерживается библиотекой OpenSSL).
• Версия 0.7.64, 0.8.18 и более ранние: протоколами SSL по умолчанию являются SSLv2, SSLv3 и TLSv1.

• Версия 1.0.5 и более поздние: шифрами SSL по умолчанию являются “ HIGH:!aNULL:!MD5 ”.
• Версия 0.7.65, 0.8.20 и более поздние: шифрами SSL по умолчанию являются “ HIGH:!ADH:!MD5 ”.
• Версия 0.8.19: шифрами SSL по умолчанию являются “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM ”.
• Версия 0.7.64, 0.8.18 и более ранние: шифрами SSL по умолчанию являются
  “ ALL:!ADH:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP ”.

Источник

Настройка HTTP и HTTPS

Службы и клиенты WCF могут взаимодействовать по протоколам HTTP и HTTPS. Параметры HTTP/HTTPS задаются с помощью служб IIS или посредством использования средства командной строки. Когда служба WCF размещается в службах IIS, параметры HTTP или HTTPS можно задать в службах IIS (с помощью средства inetmgr.exe). Если служба WCF является резидентной, параметры HTTP или HTTPS задаются с помощью средства командной строки.

Как минимум необходимо настроить регистрацию URL-адресов и добавить исключение брандмауэра для URL-адреса, который будет использоваться службой. Эти параметры можно настроить с помощью средства Netsh.exe.

Настройка резервирования пространства имен

Резервирование пространства имен назначает права на часть пространства имен URL-адреса HTTP определенной группе пользователей. Резервирование предоставляет этим пользователям право создавать службы, которые ожидают передачи данных в указанной части пространства имен. Резервирования — это префиксы URL-адресов. Это означает, что резервирование охватывает все вложенные пути пути резервирования. Резервирования пространства имен позволяют использовать подстановочные знаки двумя способами. В документации по API HTTP-сервера описывается Порядок разрешения между утверждениями пространства имен, которые используют подстановочные знаки.

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

В следующем примере используется средство Netsh.exe:

Эта команда добавляет резервирование URL-адресов для указанного пространства имен URL-адреса для учетной записи DOMAIN\user. Для получения дополнительных сведений об использовании команды netsh введите netsh http add urlacl /? в командной строке и нажмите клавишу ВВОД.

Настройка исключения брандмауэра

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

Настройка SSL-сертификатов

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

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

Настройка списка ожидания передачи данных по протоколу IP

API HTTP-сервера привязывается к IP-адресу и порту только после регистрации URL-адреса пользователем. По умолчанию API HTTP-сервера привязывается к порту в URL-адресе для всех IP-адресов компьютера. Конфликт возникает, если приложение, которое не использует API сервера HTTP, было ранее привязано к этому сочетанию IP-адреса и порта. Список прослушивания IP-адресов позволяет службам WCF сосуществовать с приложениями, которые используют порт для некоторых IP-адресов компьютера. Если в списке ожидания передачи данных по протоколу IP содержатся какие-либо записи, API HTTP-сервера привязывается только к IP-адресам, указанным в списке. Для изменения списка ожидания передачи данных по протоколу IP требуются привилегии администратора.

Используйте средство Netsh для изменения списка прослушивания IP-адресов, как показано в следующем примере:

Другие параметры конфигурации

При работе с привязкой WSDualHttpBinding клиентское соединение использует значения по умолчанию, совместимые с резервированием пространства имен и брандмауэром Windows. При необходимости настроить базовый адрес клиента для двустороннего соединения, необходимо, кроме того, настроить эти параметры HTTP в клиенте так, чтобы они соответствовали новому адресу.

Источник

SSL сертификат и настройка https на сервере

В июле 2015 года я перевел свой сайт на безопасный протокол HTTPS. Данная инструкция поможет вам без труда проделать тоже самое. Тем более, что постоянно витают слухе об отказе популярными браузерами незащищенного HTTP, в связи с чем, предвидится массовый переход на HTTPS.

Так же любой сайт на котором есть комментирование статей, форма подписки и окно поиска, можно формально подвести под закон о защите персональных данных, который требует использовать безопасные защищенные протоколы при передаче информации. Поэтому рано или поздно вам тоже придется столкнуться с необходимостью перевода сайта на HTTPS.

Как перевести сайт на HTTS

Пять простых шагов как перевести свой сайт на HTTPS

1. Получение SSL сертификата
2. Установка сертификата на сервер
3. Настройка сайта, отказ от HTTP ссылок
4. Настройка веб-сервера
5. Информирование поисковых систем

Где взять SSL сертификат для сайта

Сразу стоит определиться к какой категории относитесь вы и ваш сайт. Если вы выступаете как частное (физическое) лицо, то вам доступен лишь один вид сертификата: DV (Domain Validation). Он самый простой, выпуск его занимает минимальное время. Необходимо лишь подтвердить права владения доменным именем. Если вы представляете юридическое лицо, то вам доступны все типы сертификатов. Выбирайте любой в зависимости от потребностей вашего сайта. Но готовьтесь к тому, что проверка займет длительное время, а сам сертификат может дорого стоить.
Ранее я писал, где взять сертификат бесплатно. Этот вариант отлично подходит блогерам и владельцам персональных сайтов. Как получить такой бесплатный сертификат хорошо описано на Хабре в статье-инструкции Получаем бесплатный SSL сертификат.

Установка сертификата на сервер

Перед приобретением Ssl сертификата следует выяснить возможность его использования у себя на хостинге. Если у вас виртуальный хостинг, то настроить использование HTTPS может только поставщик услуг хостинга. Заранее выясните у него такую возможность. Если у вас сервер, не важно виртуальный или выделенный, то сертификат SSL гарантированно можно установить или использовать.

Помните, что сертификат вы получаете на домен (доменное имя), а устанавливать его надо на сервер (веб-сервер).

Установка зависит от вебсервера. Apache и NGINX настраиваются по разному. Вот неплохая инструкция как все сделать своими руками Ручная установка SSL сертификата.
Но если вы на хостинге используете панель управления VestaCP, то все заметно упрощается. Эта панель позволяет установить сертификат для вашего домена прямо из веб-интерфейса.

Предполагаю, что подобная возможность есть и в других панелях управления.

Настройка сайта, отказ от HTTP ссылок

Настройками сайта нужно добиться того, чтобы замочек защищенного соединения всегда был закрытым на всех страницах вашего сайта.

Вполне возможно, что обратившись к своему сайту в первый раз по HTTPS протоколу вы увидите такую картину:

Как видите замочек открыт, а это значит, что посетитель получает часть информации в незащищенном виде. Если щелкнуть мышкой по раскрытому замку, то можно увидеть примерно следующее:

Что нужно сделать, чтобы устранить проблему открытого замка HTTPS:

• Исправить все внутренние ссылки на использование протокола HTTPS
• Если используете картинки с внешних ресурсов, которые не работают по HTTPS, то скопируйте изображения себе на сайт
• Отказаться от внешних сервисов и систем которые не работают по HTTPS
• Убрать все плагины которые работают только по HTTP

Как исправить все ссылки на сайте

Для начала следует принять за правило использовать все ссылки без указания протокола. Это решение я подсмотрел в коде вызова скрипта Google.Adsense. Если раньше ваши ссылки выглядели так http://domainname.tld/page1.htm, то теперь они должны выглядеть так //domainname.tld/page1.htm. Ссылки такого рода будут работать и по HTTP и по HTTPS.
Если ваш сайт использует для хранения данных MySQL, а таких большинство. То проще всего сделать дамп базы. Скачать его себе на компьютер. Так как дамп базы данных MySQL представляет собой обыкновенный текстовый файл, то можно с помощью обычного текстового редактора произвести замену внутренних адресов на вариант описанный выше. После чего дамп базы данных нужно залить на сервер обратно.
Также можно поступить и с внешними ссылками. Но только не ставьте принудительно протокол HTTPS, так как нет никакой гарантии, что внешний ресурс его поддерживает.

Картинки с внешних ресурсов

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

Внешние сервисы которые не поддерживают HTTPS

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

Плагины работающие по HTTP

На моем сайте оказалось два плагина которые никак не хотели работать по безопасному протоколу HTTPS. Пришлось от них отказаться. Кроме того я проверил весь HTML код сайта на предмет загрузки скриптов и прочего с внешних ресурсов. Многие на автомате заработали по безопасному протоколу. Так же вычистил кучу мусора и неиспользуемого кода.

После проведения всех вышеописанных процедур сайт полноценно заработал по протоколу HTTPS, и замок безопасности оставался закрытым при посещении всех страниц.

Настройка веб-сервера на использование HTTPS

Для поисковых систем сайты доступные по разным протоколам http://domainname.tld и https://domainname.tld — это совершенно разные сайты. Поэтому необходимо поисковому роботу указать, кто тут главный. Для это в файле robots.txt необходимо написать название сайта с явным указанием протокола:

Затем необходимо настроить принудительную переадресацию всех запросов на протокол HTTPS. Чтобы пользователь который набрал http://domainname.tld все равно попал на безопасную версию сайта https://domainname.tld.
Если вы используете вебсервер Apache, то можно поступить следующим образом, добавьте в файл .htaccess нижеследующий код:

Информирование поисковых систем об использовании протокола HTTPS

В панели для вебмастеров поисковых систем Яндекс и Google необходимо добавить и подтвердить новый сайт, указав версию https.

[pcenter][/pcenter]

Теперь у вас в списке сайтов будет две записи по сути об одном и том же сайте. Для Google дополнительных настроек больше делать не надо, достаточно присутствия 301 редиректа. А для Яндекса у сайта работающего по HTTP необходимо указать в качестве главного зеркала HTTPS версию сайта.

[pcenter][/pcenter]

Не забудьте для нового сайта указать файл Sitemap.xml.

Яндекс не гарантирует сохранение количества страниц сайта в поиске, его позиций или посещаемости в случае изменения главного зеркала.

На этом все настройки можно считать законченными. Теперь посетители общаются с вашим сайтом по защищенному протоколу. Поисковые системы Яндекс и Google со временем поменяют адрес вашего сайта в поисковой выдаче.

Благодарности

При написании этой инструкции были использованы следующие источники

Источник