Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 3095 сообщений
Cообщения с меткой

http - Самое интересное в блогах

Следующие 30  »
rss_rss_hh_new

[Перевод] Основы Angular: HttpClient

Среда, 24 Августа 2017 г. 00:27 (ссылка)

Самый распространенный способ получить данные из web служб — это через Http. И в этой статье мы посмотрим как это можно сделать Http-запрос в Angular 4.3 через новый HttpClient.



Начиная с версии Angular 4.3 появился новый HttpClient. В этой статье описывается только новый клиент.

Читать дальше ->

https://habrahabr.ru/post/336280/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Перевод] Полное руководство по переходу с HTTP на HTTPS

Понедельник, 03 Июля 2017 г. 23:51 (ссылка)

В наше время HTTPS обязателен для каждого веб-сайта: пользователи ищут замочек в адресной строке, когда передают личные данные; Chrome и Firefox недвусмысленно помечают как небезопасные веб-сайты с формами на страницах без HTTPS; это влияет на позиции в поисковой выдаче и оказывает серьёзное влияние на приватность в целом. Кроме того, сейчас имеется несколько вариантов получить бесплатный сертификат, так что переход на HTTPS — всего лишь вопрос желания.



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



В этом руководстве я объясню отдельные компоненты и шаги и ясно изложу каждый этап установки. У вас должно всё пройти гладко, особенно если ваш хостер сам предоставляет сертификаты HTTPS — тогда высока вероятность, что вы быстро и просто всё сделаете не выходя из панели управления.



Сюда включены детальные инструкции для владельцев виртуального хостинга на cPanel, администраторов серверов Apache HTTP и nginx под Linux и Unix, а также Internet Information Server под Windows.



Начнём с основ.



HTTP, HTTPS, HTTP/2, SSL, TLS: где что?



Для описания процесса коммуникации между клиентом и сервером используется много акронимов. Люди, незнакомые с технической сутью, часто путают их.



Hypertext Transfer Protocol (HTTP) — основной протокол связи, который должны поддерживать клиент и сервер, чтобы установить соединение. Он описывает такие понятия как запросы и ответы, сессии, кэширование, аутентификация и др. Работу над протоколом, а также над языком гипертекстовой разметки Hypertext Markup Language (HTML) начал в 1989 году сэр Тим Бернерс-Ли и его группа в ЦЕРН. Первая официальная версия протокола (HTTP 1.0) вышла в 1996 году, а вскоре в 1997 году появилась версия HTTP 1.1, которая широко используется сегодня.



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



Термины SSL и TLS часто используются как взаимозаменяемые, поскольку TLS 1.0 приходит на место SSL 3.0. Сам SSL был разработан в компании Netscape, а TLS — это стандарт IETF. На момент написания этой статьи все версии SSL (1.0, 2.0, 3.0) не рекомендуются для использования из-за различных проблем с безопасностью, и современные браузеры выводят предупреждения об этом. Из стандарта TLS используются версии 1.0, 1.1 и 1.2, а версия 1.3 сейчас на стадии черновика.



Так что где-то между 1996 и 1997 годами мы получили текущую стабильную версию Интернета (HTTP 1.1 с или без SSL и TLS), которая по-прежнему поддерживается на большинстве современных веб-сайтов. Ранее HTTP использовался для несущественного трафика (например, чтения новостей), а HTTPS применяли для важного трафика (например, аутентификации и электронной коммерции): однако увеличение значения приватности привело к тому, что браузеры вроде Google Chrome сейчас помечают веб-сайты HTTP как «не конфиденциальные» и в будущем будут выводить новые предупреждения для них.



В следующем обновлении протокола HTTP — HTTP/2 — которую поддерживает всё большее количество сайтов, реализованы новые функции (сжатие, мультиплексирование, приоритет разного трафика), чтобы уменьшить задержки и увеличить производительность и безопасность.



В HTTP версии 1.1 безопасное соединение является необязательным (у вас может быть HTTP и/или HTTPS независимо друг от друга), в то время как в HTTP/2 оно на практике обязательно — даже хотя стандарт допускает HTTP/2 без TLS, но большинство разработчиков браузеров заявили, что они реализуют поддержку HTTP/2 только через TLS.



Что даёт HTTPS?



Почему в первую очередь стоит думать о HTTPS? Его внедряют по трём основным причинам:




  • Конфиденциальность

    В открытой среде, такой как Интернет, он защищает коммуникации между двумя сторонами. Например, в отсутствие HTTPS владелец точки доступа WiFi может видеть приватные данные, такие как кредитные карты, если пользователь этой точки доступа совершает покупки в онлайне.

  • Целостность

    Он гарантирует, что информация достигнет адресата в полном и нетронутом виде. Например, наш друг с точкой доступа WiFi может добавить дополнительную рекламу на наш сайт, снизить качество изображений для экономии трафика или изменить содержимое статей, которые мы читаем. HTTPS гарантирует, что веб-сайт не может быть изменён.

  • Аутентификация

    Он гарантирует, что веб-сайт в реальности является тем, за кого себя выдаёт. Например, тот же самый владелец точки доступа WiFi мог бы отправлять браузеры на поддельный сайт. HTTPS гарантирует, что веб-сайт, который представляется как example.com, действительно является example.com. Некоторые сертификаты даже проверяют правовую идентичность владельца веб-сайта, так что вы знаете, что yourbank.com принадлежит YourBank, Inc.



Криптография в основе



Конфиденциальность, целостность и аутентификация не являются уникальными особенностями HTTPS: это ключевые концепции криптографии. Давайте посмотрим на них более внимательно.



Конфиденциальность



Конфиденциальность представляет собой приватность — так и есть, она защищает информацию от чтения посторонними лицами. Обычно этот процесс предусматривает перевод информации из читаемой формы (в том числе аудио и видео), которая называется открытый текст, в зашифрованную, нечитаемую форму, которая называется шифротекст. Этот процесс именуется шифрованием. Обратный процесс — превращение нечитаемого шифротекста обратно в читаемый открытый текст — называется расшифровкой. Для шифрования и расшифровки информации существует много методов — шифровальных функций (или алгоритмов).



Чтобы две стороны могли общаться, они должны прийти к согласию по двум вопросам:




  1. Какой алгоритм (шифровальную функцию) использовать в коммуникации.

  2. Какие параметры, пароли или правила (то есть секрет) будут использоваться с выбранным методом.



Есть два основных метода шифрования:




  • симметричное

    Обе стороны владеют общим секретным ключом.

  • асимметричное

    Одна из сторон владеет парой из публичного и секретного ключей, представляя основу инфраструктуры публичных ключей (public key infrastructure, PKI).



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





Симметричное шифрование (см. большую версию)



Асимметричные методы решают проблемы такого рода — они основаны на понятии публичных и секретных ключей. Открытый текст шифруется одним ключом и может быть расшифрован с использованием парного ему ключа.



Итак, как это работает? Предположим, что у нас есть две стороны, которые желают безопасно общаться друг с другом — Алиса и Боб (в каждом учебнике всегда используются такие имена вымышленных персонажей, в справочниках по безопасности и прочих, мы уважаем эту традицию). У каждого из них есть своя пара ключей: один секретный, а один публичный. Секретные ключи известны только их соответствующим владельцам; публичные ключи открыты для всех.



Если Алиса хочет отправить сообщение Бобу, она должна раздобыть его публичный ключ, зашифровать открытый текст и отправить ему шифротекст. Он затем использует свой секретный ключ для расшифровки.



Если Боб хочет отправить сообщение Алисе, он должен раздобыть её публичный ключ, зашифровать открытый текст и отправить ей шифротекст. Она затем использует свой секретный ключ для расшифровки.





Асимметричное шифрование (см. большую версию)



Когда мы используем симметричное, а когда асимметричное шифрование?



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



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



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



Целостность



Другая проблема, которую решает HTTPS — это целостность данных: 1) гарантия, что вся информация доставляется целиком; 2) гарантия, что никто не изменяет информацию при её передаче. Для обеспечения целостной передачи информации используются алгоритмы дайджеста сообщения. Вычисление кодов аутентификации сообщений (MAC) для каждого сообщения при обмене — это процесс криптографического хеширования. Например, для получения MAC (иногда он называется тегом) используется метод, который гарантирует практическую невозможность (иногда используется термин невыполнимость) осуществить следующее:




  • изменить сообщение, не затронув тег,

  • сгенерировать одинаковый тег для двух различных сообщений,

  • обратить процесс и получить оригинальное сообщение из тега.



Аутентификация



Что насчёт аутентификации? Проблема с реальными приложениями публичной инфраструктуры ключей состоит в том, что ни у одной стороны нет способа узнать, кем на самом деле является вторая сторона — они физически разделены друг от друга. Чтобы доказать свою аутентичность второй стороне, вовлекается третья сторона, имеющая взаимное доверие — центр сертификации (CA). Этот CA выпускает сертификат с подтверждением того, что доменное имя example.com (уникальный идентификатор) связано с публичным ключом XXX. В некоторых случаях (с сертификатами EV и OV — см. ниже) CA также проверяет, что конкретная компания контролирует этот домен. Эта информация гарантирована (то есть сертифицирована) центром сертификации Х, и эта гарантия действует не раньше, чем дата Y (то есть сертификат начинает действовать с этой даты), и не позже чем дата Z (то есть сертификат заканчивает своё действие в эту дату). Вся эта информация включена в один документ, который называется сертификат HTTPS. Чтобы привести легко понимаемую аналогию — это как ID или паспорт, который выдаёт правительство страны (то есть третья сторона, которой все доверяют) — и все, кто доверяют правительству, будут также доверять сертификату (паспорту) его владельца и самому владельцу. Предполагается, конечно, что паспорт не поддельный, но подделка сертификатов выходит за рамки данной статьи.



Центры сертификации — это организации, которым доверяют подпись сертификатов. В операционных системах, таких как Windows, macOS, iOS и Android, а также в браузере Firefox есть список доверенных сертификатов.



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




  • Firefox

    “Options” -> “Advanced” -> “Certificates” -> “View Certificates” -> “Authorities”

  • Windows

    “Control Panel” -> “Internet Options” -> “Content” — “Certificates” -> “Trusted Root Certification Authorities / Intermediate Certification Authorities”

  • Mac

    “Applications” -> “Utilities” -> “Keychain Access.” В “Category” выберите “Certificates”



Все сертификаты затем проверяются и становятся доверенными. Проверка осуществляется либо операционной системой, либо браузером — доверие устанавливается напрямую или через проверенную доверенную сторону. Механизм передачи доверия известен как цепочка доверия:





Цепочка доверия (см. большую версию)



Вы можете добавить дополнительные центры сертификации, что полезно при работе с самоподписанными сертификатами (которые мы обсудим позже).



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



Типы сертификатов HTTPS



Существует несколько типов сертификатов HTTPS. Их можно классифицировать по следующим критериям.



1. Проверка подлинности




  1. Подтверждённый домен (DV)

    Самый распространённый тип сертификатов DV подтверждает, что домен соответствует определённому публичному ключу. Браузер устанавливает безопасное соединение с сервером и демонстрирует значок закрытого замка. Нажатие по значку выводит сообщение «Этот веб-сайт не предоставил информации о владельце». Для получения этого сертификата не выдвигается никаких дополнительных требований, кроме владения доменом — сертификат DV просто гарантирует, что для этого домена предъявлен правильный публичный ключ. Браузер не показывает название юридического лица. Сертификаты DV часто дёшевы ($10 в год) или бесплатны — см. разделы о Let’s Encrypt и Cloudflare ниже.

  2. Расширенное подтверждение (EV)

    Сертификаты EV подтверждают юридическое лицо, которому принадлежит веб-сайт. Это самый заслуживающий доверия тип сертификатов. Его выдают после того, как центр сертификации проверит юридическое лицо, которое контролирует домен. Юридическое лицо проверяется по нескольким условиям:




    • управление доменом (наличие сертификата DV);

    • государственный реестр для проверки, что компания зарегистрирована и действительна;

    • независимые бизнес-справочники, такие как Dunn и Bradstreet, connect.data.com от Salesforce, Yellow Pages и др.;

    • проверочный телефонный звонок;

    • проверка всех доменных имён в сертификате (подстановочные символы явно запрещены в сертификатах EV).



    Как и значок закрытого замка, сертификаты EV HTTPS показывают перед URL название проверенного юридического лица — обычно зарегистрированной компании. Некоторые устройства, такие как iOS Safari, показывают только подтверждённое юридическое лицо, полностью игнорируя URL. Нажатие на значок покажет подробности об организации, такие как полное название и юридический адрес. Стоимость этих сертификатов составляет от $150 до $300 в год.

  3. Подтверждённая организация (OV)

    Как и EV, сертификаты OV подтверждают юридическое лицо, которому принадлежит веб-сайт. Но в отличие от EV, сертификаты OV HTTPS не отображают название подтверждённого юридического лица в пользовательском интерфейсе. В результате, сертификаты OV не так популярны, поскольку у них высокие требования для проверки, но они не дают преимуществ, видимых для пользователя. Стоимость составляет от $40 до $100 в год.



2. Количество покрываемых доменов



В давние времена сертификаты HTTPS обычно содержали в поле CN единственный домен. Позже было добавлено «альтернативное имя субъекта» (SAN), чтобы один сертификат покрывал и дополнительные домены. В наши дни все сертификаты HTTPS создаются одинаково: даже в сертификате на единственный домен будет поле SAN для этого единственного домена (и второе поле SAN для версии www этого домена). Однако многие продавцы по историческим причинам по-прежнему продают сертификаты HTTPS на один и несколько доменов.




  1. Один домен

    Это самый распространённый тип сертификата, действительный для доменных имён example.com и www.example.com.

  2. Несколько доменов (UCC/SAN)

    Этот тип сертификата, также известный как сертификат Unified Communications Certificate (UCC) или Subject Alternative Names (SAN), может покрывать список доменов (до определённого предела). Он не ограничен единственным доменом — вы можете указать различные домены и поддомены. Стоимость обычно включает в себя определённое количество доменов (от трёх до пяти) с возможностью добавить больше (до определённого предела) за дополнительную плату. Рекомендуется использовать его только с родственными сайтами, потому что клиент при проверке сертификата на любом веб-сайте увидит основной домен, а также все дополнительные.

  3. Поддомены (wildcard)

    Этот тип сертификата покрывает основной домен, а также неограниченное количество поддоменов (*.example.com) — например, example.com, www.example.com, mail.example.com, ftp.example.com и т. д. Ограничение в том, что он покрывает только поддомены основного домена.



Разнообразие различных сертификатов показано в таблице:





























Тип сертификата Подтверждённый домен (DV) Подтверждённая организация (OV) Расширенное подтверждение (EV)
HTTPS HTTPS

Проверенный правообладатель
HTTPS

Проверенный правообладатель

Информация о владельце отображается в браузере
Один домен example.com, www.example.com
Несколько доменов example.com, www.example.com, mail.example.com, example.net, example.org и др.

Определённый заранее список, до некоторого лимита (обычно 100)
Поддомены *.example.com

Подходит для любого поддомена
Недоступно — все имена должны быть явно включены в сертификат и проверены центром сертификации


Конфигурация



Чтобы подвести итог, четыре компонента HTTPS требуют шифрования:




  1. Первоначальный обмен ключами

    Используются асимметричные алгоритмы (секретный и публичный ключи).

  2. Сертификация идентичности (сертификат HTTPS, выданный центром сертификации)

    Используются асимметричные алгоритмы (секретный и публичный ключи).

  3. Реальное шифрование сообщений

    Используются симметричные алгоритмы (предварительно разделённый совместный секрет).

  4. Дайджест сообщений

    Используются алгоритмы криптографического хеширования



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



Например, выбор ECDHE-RSA-AES256-GCM-SHA384 означает, что обмен ключами будет производиться по алгоритму Elliptic Curve Diffie-Hellman Ephemeral (ECDHE); центр сертификации подписал сертификат при помощи алгоритма Rivest-Shamir-Adleman (RSA); симметричное шифрование сообщений будет использовать шифр Advanced Encryption Standard (AES) с 256-битным ключом и будет работать в режиме GCM; целостность сообщений будет обеспечивать алгоритм безопасного хеширования SHA, с использованием 384-битных дайджестов. (Доступен полный список комбинаций алгоритмов).



Итак, нужно сделать выбор некоторых конфигураций.



Наборы шифров



Выбор набора шифров для использования — это компромисс между совместимостью и безопасностью:




  • Для совместимости со старыми браузерами нужно, чтобы сервер поддерживал старые наборы шифров.

  • Однако многие старые наборы шифров больше не считаются безопасными.



OpenSSL перечисляет поддерживаемые комбинации (см. выше) в порядке убывания их криптографической стойкости. Так сделано, чтобы во время первоначального рукопожатия между клиентом и сервером они перебирали комбинации начиная с самой сильной до тех пор, пока не найдут комбинацию, которая поддерживается обеими сторонами. Есть смысл пробовать сначала самую безопасную комбинацию, а затем постепенно ослаблять безопасность, если нет других вариантов.



Википедия содержит исчерпывающий список алгоритмов для всех компонентов TLS и указывает их поддержку в разных версиях SSL и TLS.



Mozilla SSL Configuration Generator — очень полезный и крайне рекомендуемый справочник, какие криптографические методы использовать на сервере. Мы позже будем использовать его в реальных серверных конфигурациях.



Типы ключей



Сертификаты Elliptic Curve Cryptography (ECC) быстрее обрабатываются и используют меньше CPU, чем сертификаты RSA, что особенно важно для мобильных клиентов. Однако некоторые сервисы, такие как Amazon, CloudFront и Heroku на момент написания этой статьи пока не поддерживают сертификаты ECC.



256-битная длина ключа для ECC считается достаточной.



Сертификаты Rivest Shamir Adleman (RSA) более медленные, но совместимы с большим разнообразием старых серверов. Ключи RSA больше по размеру, так что 2048-битный ключ RSA считается минимально допустимым. Сертификаты RSA с ключами 4096 бит и больше могут ухудшать производительность — к тому же, скорее всего, они подписаны 2048-битным ключом посредника, что по большей части подрывает дополнительную защиту!



Вы могли заметить расплывчатость заявлений, сделанных выше, и отсутствие каких-либо чисел. То, что может нагрузить один сервер, не нагрузит другой сервер. Лучший способ определить влияние на производительность — это проверить загрузку на своём собственном сервере, с реальным веб-сайтом и реальными посетителями. И даже это изменится со временем.



Процедуры



Для получения сертификаты HTTPS выполните следующие шаги:




  1. Создайте пару из секретного и публичного ключей и подготовьте запрос на подпись сертификата (Certificate Signing Request, CSR), включающий информацию об организации и публичном ключе.

  2. Свяжитесь с центром сертификации и запросите сертификат HTTPS на основании CSR.

  3. Получите подписанный сертификат HTTPS и установите его на своём сервере.



Есть набор файлов, содержащих различные компоненты инфраструктуры публичных ключей (PKI): секретный и публичный ключи, CSR и подписанный сертификат HTTPS. Чтобы ещё больше всё усложнить, разные стороны используют разные названия (и расширения) для именования одной и той же вещи.



Для начала, есть два популярных формата хранения информации — DER и PEM. Первый из них (DER) бинарный, а второй (PEM) — это файл DER в кодировке base64 (текст). По умолчанию Windows напрямую использует формат DER, а мир свободных систем (Linux и UNIX) использует формат PEM. Существуют инструменты (OpenSSL) для конвертации файлов из одного формата в другой.



В качестве примеров мы будем использовать такие файлы:




  • example.com.key

    Файл в формате PEM с секретным ключом. Расширение .key не является стандартом, так что кто-то может использовать его, а кто-то нет. Файл должен быть защищён и доступен только для суперпользователя.

  • example.com.pub

    Файл в формате PEM с публичным ключом. Вам на самом деле не нужен этот файл (и он никогда не будет явно присутствовать), потому что его можно сгенерировать из секретного ключа. Он включён сюда только для примера.

  • example.com.csr

    Это запрос на подпись сертификата. Файл в формате PEM содержит информацию об организации, а также публичный ключ сервера. Его нужно отправить в центр сертификации, выдающий сертификаты HTTPS.

  • example.com.crt

    Сертификат HTTPS, выданный центром сертификации. Это файл в формате PEM, который содержит публичный ключ сервера, информацию об организации, подпись центра сертификации, даты начала и окончания срока действия и др. Расширение .crt не является стандартом; часто используются другие расширения, в том числе .cert и .cer.



Названия файлов (и расширения) не стандартизированы; можете использовать любые. Я выбрал такие названия, потому что они кажутся говорящими и делают очевидным, какую функцию выполняет каждый компонент. Вы можете использовать любую схему именования, которая для вас имеет смысл, главное — указать соответствующие файлы ключей и сертификата в командах и конфигурации сервера в процессе настройки.



Секретный ключ — это случайно сгенерированная строка определённой длины (мы используем 2048 бит), которая выглядит примерно так:



-----BEGIN RSA PRIVATE KEY-----

MIIEowIBAAKCAQEAm+036O2PlUQbKbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9N

i8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4E

S17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWu

Q30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnf

b/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDil

Tt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQgNQIDAQABAoIBAEAO2KVM02wTKsWb

dZlXKEi5mrtofLhkbqvTgVE7fbOKnW8FJuqCl+2NMH31F1n03l765p4dNF4JmRhv

/+ne4vCgOPHR/cFsH4z/0d5CpHMlC7JZQ5JjR4QDOYNOpUG51smVamPoZjkOlyih

XGk/q72CxeU6F/gKIdLt6Dx03wBosIq9IAE8LwdMnioeuj18qaVg195OMeIOriIn

tpWP4eFya5rTpIFfIdHdIxyXsd6hF/LrRc9BMWTY1/uOLrpYjTf7chbdNaxhwH7k

buvKxBvCvmXmd6v/AeQQAXbUkdSnbTKDaB9B7IlUTcDJyPBJXvFS1IzzjN6vV+06

XBwHx5ECgYEAyRZLzwnA3bw8Ep9mDw8JHDQoGuQkFEMLqRdRRoZ+hxnBD9V9M0T6

HRiUFOizEVoXxf6zPtHm/T7cRD8AFqB+pA/Nv0ug6KpwUjA4Aihf5ADp0gem0DNw

YlVkCA6Bu7c9IUlE0hwF7RLB7YrryJVJit9AymmUTUUHCQTWW2yBhC8CgYEAxoHS

HGXthin5owOTNPwLwPfU2o7SybkDBKyW69uTi0KxAl3610DjyA/cV2mxIcFlPv1y

HualGd9eNoeCMBy/AUtjzI0K77yeRpjj321rj6k8c8bYWPHH539SiBXLWTY/WQ0w

pxfT3d/Z4QMh5d6p+p5f3UIrXESYQd+fAaG5tNsCgYEAksTdTB4YUT9EsWr6eN9G

jPlclFQUKV3OMvq77bfYvg8EJORz32nnDDmWS7SUjoOtemwutBlMeWbaKk25aMp3

5JNMXuV6apeMJ9Dd8GU7qBUqlIvVK31/96XPvzmnYzWZPqRVwO2HPcRFG3YcJmkg

JmZQyexJvCQ3wFNxiYUm+y0CgYBXQSMhFnCUg4jWbbDcHlnwRT+LnjHrN2arPE3O

eKLfGL6DotmqmjxFaStaRPv2MXMWgAMUsB8sQzG/WEsSaOBQaloAxJJlFIyhzXyE

bi1UZXhMD8BzQDu1dxLI/IN4wE6SDykumVuocEfuDxlsWDZxEgJjWD2E/iXK9seG

yRa+9wKBgEydVz+C1ECLI/dOWb20UC9nGQ+2dMa+3dsmvFwSJJatQv9NGaDUdxmU

hRVzWgogZ8dZ9oH8IY3U0owNRfO65VGe0sN00sQtMoweEQi0SN0J6FePiVCnl7pf

lvYBaemLrW2YI2B7zk5fTm6ng9BW/B1KfrH9Vm5wLQBchAN8Pjbu

-----END RSA PRIVATE KEY-----




Держите ключ в секрете! Это значит, защитите его с помощью очень ограниченных разрешений (600) и никому не разглашайте.



Его напарник — публичный ключ — выглядит примерно так:



-----BEGIN PUBLIC KEY-----

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQbKbSSs2ik

6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3OWb1aBW5

e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYOcfOmMN+H

fBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wmwZEIQTIN

WniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZEUQs5IBC

eVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2tjtp+LQg

NQIDAQAB

-----END PUBLIC KEY-----




Запрос на получение сертификата выглядит примерно так:



-----BEGIN CERTIFICATE REQUEST-----

MIICzjCCAbYCAQAwgYgxFDASBgNVBAMMC2V4YW1wbGUuY29tMQswCQYDVQQLDAJJ

VDEPMA0GA1UECAwGTG9uZG9uMRIwEAYDVQQKDAlBQ01FIEluYy4xIDAeBgkqhkiG

9w0BCQEWEWFkbWluQGV4YW1wbGUuY29tMQswCQYDVQQGEwJHQjEPMA0GA1UEBwwG

TG9uZG9uMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm+036O2PlUQb

KbSSs2ik6O6TYy6+Zsas5oAk3GioGLl1RW9Ni8kagqdnD69Et29m1vl5OIPsBoW3

OWb1aBW5e3J0x9prXI1W/fpvuP9NmrHBUN4ES17VliRpfVH3aHfPC8rKpv3GvHYO

cfOmMN+HfBZlUeKJKs6c5WmSVdnZB0R4UAWuQ30aHEBVqtrhgHqYDBokVe0/H4wm

wZEIQTINWniCOFR5UphJf5nP8ljGbmPxNTnfb/iHS/chjcjF7TGMG36e7EBoQijZ

EUQs5IBCeVefOnFLK5jLx+BC//X+FNzByDilTt+l28I/3ZN1ujhak73YFbWjjLR2

tjtp+LQgNQIDAQABoAAwDQYJKoZIhvcNAQELBQADggEBAGIQVhXfuWdINNfceNPm

CkAGv4yzpx88L34bhO1Dw4PYWnoS2f7ItuQA5zNk9EJhjkwK8gYspK7mPkvHDbFa

Um7lPSWsm3gjd3pU7dIaHxQ+0AW9lOw5ukiBlO4t3qgt+jTVZ3EhMbR0jDSyjTrY

kTgfuqQrGOQSmLb5XviEtCcN0rseWib3fKIl8DM69JiA2AALxyk7DCkS1BqLNChT

pnbgvtlUhc4yFXNCtwPGskXIvLsCn2LRy+qdsPM776kDLgD36hK0Wu14Lpsoa/p+

ZRuwKqTjdaV23o2aUMULyCRuITlghEEkRdJsaXadHXtNd5I5vDJOAAt46PIXcyEZ

aQY=

-----END CERTIFICATE REQUEST-----




Этот конкретный CSR содержит публичный ключ сервера и информацию о компании ACME Inc., которая находится в Лондоне, Великобритания, и владеет доменом example.com.



Наконец, подписанный сертификат HTTPS выглядит примерно так:



-----BEGIN CERTIFICATE-----

MIIDjjCCAnYCCQCJdR6v1+W5RzANBgkqhkiG9w0BAQUFADCBiDEUMBIGA1UEAwwL

ZXhhbXBsZS5jb20xCzAJBgNVBAsMAklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNV

BAoMCUFDTUUgSW5jLjEgMB4GCSqGSIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20x

CzAJBgNVBAYTAkdCMQ8wDQYDVQQHDAZMb25kb24wHhcNMTYwNDE5MTAzMjI1WhcN

MTcwNDE5MTAzMjI1WjCBiDEUMBIGA1UEAwwLZXhhbXBsZS5jb20xCzAJBgNVBAsM

AklUMQ8wDQYDVQQIDAZMb25kb24xEjAQBgNVBAoMCUFDTUUgSW5jLjEgMB4GCSqG

SIb3DQEJARYRYWRtaW5AZXhhbXBsZS5jb20xCzAJBgNVBAYTAkdCMQ8wDQYDVQQH

DAZMb25kb24wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCb7Tfo7Y+V

RBsptJKzaKTo7pNjLr5mxqzmgCTcaKgYuXVFb02LyRqCp2cPr0S3b2bW+Xk4g+wG

hbc5ZvVoFbl7cnTH2mtcjVb9+m+4/02ascFQ3gRLXtWWJGl9Ufdod88Lysqm/ca8

dg5x86Yw34d8FmVR4okqzpzlaZJV2dkHRHhQBa5DfRocQFWq2uGAepgMGiRV7T8f

jCbBkQhBMg1aeII4VHlSmEl/mc/yWMZuY/E1Od9v+IdL9yGNyMXtMYwbfp7sQGhC

KNkRRCzkgEJ5V586cUsrmMvH4EL/9f4U3MHIOKVO36Xbwj/dk3W6OFqTvdgVtaOM

tHa2O2n4tCA1AgMBAAEwDQYJKoZIhvcNAQEFBQADggEBABwwkE7wX5gmZMRYugSS

7peSx83Oac1ikLnUDMMOU8WmqxaLTTZQeuoq5W23xWQWgcTtfjP9vfV50jFzXwat

5Ch3OQUS53d06hX5EiVrmTyDgybPVlfbq5147MBEC0ePGxG6uV+Ed+oUYX4OM/bB

XiFa4z7eamG+Md2d/A1cB54R3LH6vECLuyJrF0+sCGJJAGumJGhjcOdpvUVt5gvD

FIgT9B04VJnaBatEgWbn9x50EP4j41PNFGx/A0CCLgbTs8kZCdhE4QFMxU9T+T9t

rXgaspIi7RA4xkSE7x7B8NbvSlgP79/qUe80Z7d8Oolva6dTZduByr0CejdfhLhi

mNU=

-----END CERTIFICATE-----




Все части связаны и должны соответствовать друг другу. Последний сертификат был сгенерирован только ради примера — это так называемый самоподписанный сертификат, потому что он не подписан признанным центром сертификации.



Мы проиллюстрируем этот процесс реальными шагами, которые нужно сделать в cPanel, Linux, FreeBSD и Windows. Это универсальный процесс, подходящий для всех типов сертификатов. Если вы хотите получить бесплатный сертификат DV, то следуйте другим процедурам, описанным в разделах Let’s Encrypt и Cloudflare.



Шаг 1. Создать секретный ключ и запрос на получение сертификата



В следующих примерах мы будем использовать 2048-битные сертификаты RSA, по причине их большей совместимости. Если ваш провайдер, у которого установлен сервер, поддерживает ECC (например, если вы не пользуетесь услугами Heroku или AWS), то можете предпочесть использовать ECC.



cPanel




  1. Войдите в cPanel своего хоста.

  2. Прокрутите вниз до раздела “Security” и нажмите “SSL/TLS”.





    Раздел “Security” в cPanel (см. большую версию)




  3. Теперь вы в разделе “SSL/TLS Manager”. Нажмите “Private Keys (KEY)” для создания нового секретного ключа.





    “SSL/TLS Manager” в cPanel (см. большую версию)




  4. Вас перенаправят на страницу “Generate, Paste or Upload” для нового “Private

    Key”. Там выберете 2048 бит в выпадающем меню и нажмите “Generate”.





    Управление секретным ключом (“Private Key”) в cPanel (см. большую версию)




  5. Будет сгенерирован новый секретный ключ, а вы получите подтверждение на экране:





    Подтверждение секретного ключа в cPanel (см. большую версию)




  6. Если вернётесь назад в раздел “Private Keys”, то увидите там новый ключ:





    Раздел “Private Keys” в cPanel с новым сгенерированным ключом (см. большую версию)




  7. Вернитесь в раздел “SSL/TLS Manager”. Нажмите “Certificate Signing Requests (CSR)” для создания нового запроса на получение сертификата.





    Раздел “SSL/TLS Manager” в cPanel (см. большую версию)




  8. Теперь вы увидите форму “Generate Service Request”. Выберите созданный ранее секретный ключ и заполните поля. Правильно ответьте на все вопросы (они будут открыты для просмотра в вашем подписанном сертификате!), особенное внимание уделите разделу “Domains”, который должен в точности совпадать с доменным именем, для которого вы запрашиваете сертификат HTTPS. Включите туда только домен верхнего уровня (example.com); центр сертификации обычно сам добавляет поддомен www (то есть www.example.com). По окончании нажмите кнопку “Generate”.





    Форма “Create New Certificate Signing Request” в cPanel (см. большую версию)




  9. Будет сгенерирован новый CSR, а вы увидите окно с подтверждением:





    Подтверждение создания CSR в cPanel (см. большую версию)




  10. Если вы вернётесь назад в раздел “Certificate Signing Request”, то увидите там новый CSR:





    Раздел “Certificate Signing Request” в cPanel с новым сгенерированным CSR (см. большую версию)






Linux, FreeBSD



Убедитесь, что установлен OpenSSL. Вы можете проверить это:



openssl version



Если нет, то откройте консоль и установите его для своей платформы:




  • Debian, Ubuntu и клоны

    sudo apt-get install openssl

  • Red Hat, CentOS и клоны

    sudo yum install openssl

  • FreeBSD

    make -C /usr/ports/security/openssl install clean



Затем сгенерируйте секретный ключ и CSR одной командой:



openssl req -newkey rsa:2048 -nodes -keyout example.com.key -out example.com.csr



Секретный ключ будет сгенерирован, а вам нужно ответить на несколько вопросов для CSR:



Generating a 2048 bit RSA private key

........................+++

................................................................+++

writing new private key to 'example.com.key'

-----

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.




Правильно ответьте на все вопросы (они будут открыты для просмотра в вашем подписанном сертификате!), особенное внимание уделите разделу “Common Name” (например, сервер FQDN или ВАШЕ имя), который должен в точности совпадать с доменным именем, для которого вы запрашиваете сертификат HTTPS. Включите туда только домен верхнего уровня (example.com); центр сертификации обычно сам добавляет поддомен www (то есть www.example.com):



Country Name (2 letter code) [AU]:GB

State or Province Name (full name) [Some-State]:London

Locality Name (eg, city) []:London

Organization Name (eg, company) [Internet Widgits Pty Ltd]:ACME Inc.

Organizational Unit Name (eg, section) []:IT

Common Name (e.g. server FQDN or YOUR name) []:example.com

Email Address []:admin@example.com



Please enter the following 'extra' attributes

to be sent with your certificate request

A challenge password []:

An optional company name []:




Internet Information Server под Windows




  1. Откройте “Start” -> “Administrative Tools” -> “Internet Information Services (IIS) Manager”. Нажмите на имя сервера. Двойным щелчком откройте “Server Certificates” в средней колонке:





    Откройте “Internet Information Services (IIS) Manager”. Двойным щелчком откройте “Server Certificates”. (см. большую версию)




  2. Нажмите “Create Certificate Request” в правой колонке.





    Нажмите “Create Certificate Request” в правой колонке. (см. большую версию)




  3. Введите информацию о своей организации, особое внимание уделите графе “Common Name”, значение в которой должно соответсвовать вашему доменному имени. Нажмите “Next”.





    Введите информацию о своей организации. (см. большую версию)




  4. Оставьте значение по умолчанию в поле “Cryptographic Service Provider.” Установите “Bit length” на 2048. Нажмите “Next”.





    Установите “Bit length” на 2048. (см. большую версию)




  5. Выберите место для сохранения сгенерированного CSR и нажмите “Finish”.





    Выберите место для сохранения сгенерированного CSR и нажмите “Finish”. (см. большую версию)






Шаг 2. Приобретение сертификата HTTPS



Чтобы получить сертификат для вашего веб-сайта, сначала купите кредит на сертификат HTTPS выбранного типа (DV, OV, EV, один сайт, несколько сайтов, поддомены — см. выше) у продавца сертификатов. По окончании процесса вам нужно будет отправить запрос на получение сертификата, который потратит купленный кредит для выбранного домена. Вас попросят предоставить (то есть вставить в поле для загрузки) весь текст CSR, включая строки -----BEGIN CERTIFICATE REQUEST----- и -----END CERTIFICATE REQUEST-----. Если вам нужен сертификат EV или OV, то нужно будет указать юридическое лицо, для которого вы запрашиваете сертификат. У вас также могут попросить дополнительные документы, подтверждающие тот факт, что вы представляете эту компанию. Затем регистратор сертификатов проверит ваш запрос (и все сопутствующие документы) и выдаст подписанный сертификат HTTPS.



Получение сертификата HTTPS



У вашего хостинг-провайдера или регистратора HTTPS может быть другая процедура регистрации, но общая логика одинакова.




  1. Найти продавца сертификатов HTTPS.

  2. Выбрать тип сертификата (DV, OV, EV, один сайт, несколько сайтов, поддомены) и добавить его в корзину. Выбрать предпочитаемый метод оплаты и совершить платёж.

  3. Активировать новый сертификат HTTPS для своего домена. Вы можете или вставить в форму, или загрузить файл с запросом на подпись сертификата. Система извлечёт информацию для сертификата из CSR.

  4. Вас попросят выбрать метод «утверждения контроля домена» (“Domain Control Validation”, DCV) — либо по электронной почте, либо загрузкой файла HTML (на основе HTML), либо путём добавления записи TXT к своему файлу доменной зоны (на основе DNS). Следуйте инструкциям по указанному методу DCV для утверждения.

  5. Подождите несколько минут, пока осуществляется утверждение и готовится сертификат HTTPS. Скачайте сертификат.



Самоподписанные сертификаты



Существует возможность самому подписать сертификат, а не отдавать это право центру сертификации. Это хорошо для целей тестирования, потому что с криптографической точки зрения самоподписанный сертификат не отличается от любого другого, но браузеры не станут ему доверять, а начнут показывать предупреждение безопасности — вы можете выдавать себя за кого угодно, но это не проверено доверенной третьей стороной. Если пользователь доверяет веб-сайту, он может добавить исключение в свой браузер, который сохранит сертификат и будет доверять сайту при будущих визитах.



Например, выше опубликован самоподписанный сертификат — вы можете использовать его для домена example.com, и он будет работать в течение своего срока действия.



Можно создать самоподписанный сертификат на любой платформе, где есть OpenSSL.



openssl x509 -signkey example.com.key -in example.com.csr -req -days 365 -out example.com.crt



Как только сертификат сгенерирован, вам нужно установить его на свой сервер. Если у вас хостинг и сервис регистрации HTTPS от одного провайдера (многие хостинг-провайдеры также продают сертификаты HTTPS), то может действовать автоматическая процедура установки и активации вашего нового сертификата HTTPS для веб-сайта. Если вы хоститесь где-то в другом месте, то нужно скачать сертификат и сконфигурировать сервер для его использования.



Шаг 3. Установка сертификата HTTPS для своего веб-сайта



cPanel




  1. Вернитесь в “SSL/TLS Manager”. Нажмите “Certificates (CRT)” для импортирования нового сертификата.





    Раздел “SSL/TLS Manager” в cPanel (см. большую версию)




  2. Вас перенаправят на страницу “Paste, Upload or Generate” для нового “Certificate”. Вставьте содержимое файла сертификата, полученного от регистратора HTTPS, или загрузите его с помощью кнопки “Browse”.





    Импорт нового сертификата HTTPS в cPanel (см. большую версию)




  3. После того как вы вставили содержимое нового сертификата HTTPS, оно будет проанализировано, а чисто текстовые значения покажут вам для подтверждения. Просмотрите содержимое и нажмите кнопку “Save Certificate”.





    Просмотр содержимого и подтверждение сертификата HTTPS в cPanel (см. большую версию)




  4. Новый сертификат будет сохранён, а вы увидите окно с подтверждением.





    Подтверждение сертификата HTTPS в cPanel (см. большую версию)




  5. Если вернётесь в раздел “Certificates (CRT)”, то увидите там свой новый сертификат HTTPS.





    Страница “Certificates” в cPanel с новым сертификатом HTTPS. (см. большую версию)




  6. Вернитесь в раздел “SSL/TLS Manager”. Нажмите “Install and Manage SSL for your website (HTTPS)”, чтобы присвоить существующему веб-сайту новый сертификат.





    Раздел “SSL/TLS Manager” в cPanel. (см. большую версию)




  7. Вам будет предложена новая форма “Install an SSL Website”. Нажмите кнопку “Browse Certificates” и выберите свой сертификат HTTPS. Выберите домен своего веб-сайта из выпадающего меню (если он не выбран автоматически) и проверьте значения полей “Certificate” и “Private Key”.





    Форма “Install an SSL Website” в cPanel. (см. большую версию)






Проверьте, что у вас есть доступ к веб-сайту по адресу https://www.example.com. Если всё работает нормально, то вы, вероятно, захотите поставить постоянный редирект HTTP-трафика на HTTPS. Для этого нужно добавить несколько строчек в файл .htaccess (если у вас веб-сервер Apache) в корневой директории на своём сервере.



RewriteEngine On



RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]




Если файл .htaccess уже существует, то вставьте только строчки RewriteCond и RewriteRule сразу после существующей директивы RewriteEngine On.



Linux, FreeBSD



Разместите в соответствующих директориях сгенерированный секретный ключ (example.com.key), запрос на подпись сертификата (example.com.csr) и действительный сертификат HTTPS (example.com.crt):




  • Debian, Ubuntu и клоны, FreeBSD

    cp example.com.crt /etc/ssl/certs/

    cp example.com.key /etc/ssl/private/

    cp example.com.csr /etc/ssl/private/

  • Red Hat, CentOS и клоны

    cp example.com.crt /etc/pki/tls/certs/

    cp example.com.key /etc/pki/tls/private/

    cp example.com.csr /etc/pki/tls/private/

    restorecon -RvF /etc/pki



Файлы должны принадлежать руту и быть защищены настройкой разрешения 600.




  • Debian, Ubuntu и клоны

    chown -R root. /etc/ssl/certs /etc/ssl/private

    chmod -R 0600 /etc/ssl/certs /etc/ssl/private

  • Red Hat, CentOS и клоны

    chown -R root. /etc/pki/tls/certs /etc/pki/tls/private

    chmod -R 0600 /etc/pki/tls/certs /etc/pki/tls/private

  • FreeBSD

    chown -R root:wheel /etc/ssl/certs /etc/ssl/private

    chmod -R 0600 /etc/ssl/certs /etc/ssl/private



Apache



Чтобы активировать HTTPS на своём сайте, нужно сделать следующее:




  • убедиться, что на сервере установлен mod_ssl,

  • загрузить на сервер файл полученного сертификата HTTPS (.crt),

  • отредактировать файлы конфигурации сервера Apache.



Начните с проверки mod_ssl. В зависимости от операционной системы, должен работать один из вариантов:



apache2 -M | grep ssl

или

httpd -M | grep ssl



Если mod_ssl установлен, то вы получите такой ответ…



ssl_module (shared)

Syntax OK




… или нечто похожее.



Если он не установлен или не работает, то попробуйте это:




  • Debian, Ubuntu и клоны

    sudo a2enmod ssl

    sudo service apache2 restart

  • Red Hat, CentOS и клоны

    sudo yum install mod_ssl

    sudo service httpd restart

  • FreeBSD

    make -C /usr/ports/www/apache24 config install clean

    apachectl restart



Отредактируйте файл конфигурации Apache (httpd.conf):




  • Debian, Ubuntu

    /etc/apache2/apache2.conf

  • Red Hat, CentOS

    /etc/httpd/conf/httpd.conf

  • FreeBSD

    /usr/local/etc/apache2x/httpd.conf





Listen			80
Listen 443


ServerName example.com
ServerAlias www.example.com
Redirect 301 / https://www.example.com/



ServerName example.com
Redirect 301 / https://www.example.com/



ServerName www.example.com
...
SSLEngine on
SSLCertificateFile/path/to/signed_certificate_followed_by_intermediate_certs
SSLCertificateKeyFile /path/to/private/key

# Uncomment the following directive when using client certificate authentication
#SSLCACertificateFile /path/to/ca_certs_for_client_authentication

# HSTS (mod_headers is required) (15768000 seconds = 6 months)
Header always set Strict-Transport-Security "max-age=15768000"
...


# intermediate configuration, tweak to your needs
SSLProtocol all -SSLv3
SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
SSLHonorCipherOrder on
SSLCompression off
SSLSessionTickets off

# OCSP Stapling, only in httpd 2.3.3 and later
SSLUseStapling on
SSLStaplingResponderTimeout 5
SSLStaplingReturnResponderErrors off
SSLStaplingCache shmcb:/var/run/ocsp(128000)


Эта конфигурация была сгенерирована с помощью упомянутого ранее Mozilla SSL Configuration Generator. С его помощью проверьте актуальность конфигурации. Отредактируйте правильные пути для сертификата и секретного ключа. Показанная здесь конфигурация сгенерирована с промежуточными настройками — прочитайте об ограничениях и конфигурациях браузера для каждой настройки, прежде чем выбрать наиболее подходящую для себя.



В коде были сделаны некоторые изменения, чтобы обрабатывать редиректы с HTTP на HTTPS, а также с не-www на домен с www (полезно для задач SEO).



Nginx



Отредактируйте файл конфигурации nginx (nginx.conf):




  • Debian, Ubuntu, Red Hat, CentOS

    /etc/nginx/nginx.conf

  • FreeBSD

    /usr/local/etc/nginx/nginx.conf



    server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
    }

    server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;

    # Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits
    ssl_dhparam /path/to/dhparam.pem;

    # intermediate configuration. tweak to your needs.
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;
    resolver ;

    ....
    }



Эта конфигурация была сгенерирована с помощью упомянутого ранее Mozilla SSL Configuration Generator. С его помощью проверьте актуальность конфигурации. Отредактируйте правильные пути для сертификата и секретного ключа. Показанная здесь конфигурация сгенерирована с промежуточными настройками — прочитайте об ограничениях и конфигурациях браузера для каждой настройки, прежде чем выбрать наиболее подходящую для себя.



Генератор автоматически генерирует код для обработки редиректов с HTTP на HTTPS и изначально активирует поддержку HTTP/2!



Internet Information Server под Windows




  1. Откройте “Start” -> “Administrative Tools” -> “Internet Information Services (IIS) Manager”. Нажмите на название сервера. Двойным щелчком откройте “Server Certificates” в средней колонке.





    Откройте “Internet Information Services (IIS) Manager”. Двойным щелчком откройте “Server Certificates”. (см. большую версию)




  2. Нажмите “Complete Certificate Request” в правой колонке.





    Нажмите “Complete Certificate Request” в правой колонке. (см. большую версию)




  3. Выберите файл подписанного сертификата (example.com.crt), который вы получили от центра сертификации. Введите какое-нибудь название в поле “Friendly name”, чтобы различать сертификаты впоследствии. Поместите новый сертификат в хранилище сертификатов “Personal” (IIS 8+). Нажмите “OK”.





    Выберите файл подписанного сертификата. (см. большую версию)




  4. Если процесс прошёл нормально, вы должны увидеть сертификат на вкладке “Server Certificates”.





    Вы должны увидеть сертификат на вкладке “Server Certificates”. (см. большую версию)




  5. Расширьте вкладку с названием сервера. В разделе “Sites” выберите веб-сайт, которому вы хотите присвоить сертификат HTTPS. Нажмите “Bindings” в правой колонке.





    Выберите веб-сайт и нажмите “Bindings”. (см. большую версию)




  6. В окне “Site Bindings” нажмите кнопку “Add”.





    Нажмите кнопку “Add”. (см. большую версию)




  7. В новом окне выберите:


    • “Type”: “https”

    • “IP address”: “All Unassigned”

    • “Port”: “443”



    В поле “SSL Certificate” выберите установленный сертификат HTTPS по присвоенному ему имени. Нажмите “OK”.





    Выберите “HTTPS” и укажите установленный сертификат HTTPS. (см. большую версию)<
Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Как начать работать с блокчейном Emer

Понедельник, 29 Мая 2017 г. 06:55 (ссылка)

Введение



Блокчейн-платформа Эмер существует уже три года, и на её основе работает ряд распределённых сервисов. Наибольший интерес она вызывает в среде бизнес-применений (b2b), а также IT-профессионалов, в основном – связистов и безопасников.

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

Основная идея платформы Emer: Много сервисов на одном блокчейне. Иными словами – установите единственный блокчейн, и получите пакет сервисов, а также возможность легко добавлять свои сервисы. Ряд компаний, таких как Deloitte и I-teco оценили возможности платформы, и уже используют её для решения своих задач. Данная статья расскажет Вам, как получить доступ к блокчейну Emer и использовать как существующие сервисы, так и внедрять свои.



Читать дальше →

https://habrahabr.ru/post/329632/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Комментарии (0)КомментироватьВ цитатник или сообщество
Аноним

Среда, 01 Декабря 1970 г. 03:00 (ссылка)

Комментарии ()КомментироватьВ цитатник или сообщество
Аноним

Среда, 01 Декабря 1970 г. 03:00 (ссылка)

Комментарии ()КомментироватьВ цитатник или сообщество
zabarik

Канадца в костюме героя Fallout приняли за террориста

Суббота, 15 Апреля 2017 г. 23:07 (ссылка)

Житель канадского Гpанд Прeйри пeреполошил чуть ли нe весь гоpод, пpогулявшись по улицам в костюме пeрсонажа Fallout: New Vegas с флaгом Новoй калифорнийской рeспублики в руках. Пpохожие рeшили, что пeред ними терpорист, за спиной у котоpого закрeплена бомба, и вызвали полицию. На cамом дeле мужчина напpавлялся в ателье, чтобы попpоcить помощи с новым костюмом, который у нeго никак нe получалось закончить. Чтобы нe тащить костюм в руках или в сумке, он пpосто надeл его на себя.

Тем нe менeе, на место «пpоисшествия» прибыло нe менeе вoсьми вoоруженных полицейских. Они эвакуиpовали ателье, в котоpое вoшел косплеер, а затем устpоило пeреговoры с прeдполaгаемым терpористом. В итогe, виновника паники забpали в участок, но очень скоpо выпустили, нe прeдъявив никаких обвинeний.

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<http - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda