Самоподписанный ssl сертификат для ip адреса

Самоподписанный ssl сертификат для ip адреса

Сертификаты для localhost

Иногда разработчикам нужен сертификат для доменного имени “localhost” — для локальной разработки, или для распространения внутри нативных приложений для взаимодействия с web-приложением. Let’s Encrypt не предоставляет сертификатов для “localhost”, т.к. во-первых, у этого доменного имени нет определённого владельца, и во-вторых, нет домена первого уровня — например, “.com” или “.net”. Теоретически, возможно настроить доменное имя так, чтобы оно резолвилось на адрес 127.0.0.1 , и выпустить для него сертификат после прохождения проверки DNS. Тем не менее, есть более удачные решения.

Для локальной разработки

При разработке web-приложения обычно запускают локальный web-сервер (Apache, Nginx), настроенный на http://localhost:8000/ . Однако, браузеры по-разному обрабатывают HTTP- и HTTPS-запросы. На HTTPS-странице попытка загрузить Javascript по HTTP-протоколу будет заблокирована. Поэтому, при локальной разработке, используя HTTP, скрипты будут загружаться нормально, но после выкладки на боевые HTTPS-сервера возникнут проблемы. Чтобы избежать такой ситуации, нужно настроить доступ по HTTPS на локальном web-сервере. Но как избавиться от постоянных сообщений об ошибке сертификата, как увидеть “зелёный замок” в адресной строке?

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

Для нативных приложений, взаимодействующих с web-приложениями

Время от времени, разработчики вынуждены выпускать загружаемые нативные приложения, для расширения функциональности и совместного использования с web-приложениями. Например, десктоп-приложения Dropbox и Spotify умеют сканировать файлы на дисках компьютера, что невозможно для web-приложений. Общий подход в реализации таких нативных приложений состоит в запуске локального web-сервера, и обмену данными с web-приложением через XMLHTTPRequest (XHR) или WebSockets. Web-приложения, как правило, используют HTTPS, поэтому XHR- или WebSockets-запросы по небезопасному протоколу HTTP будут отклонены. Это называется “блокировка смешаного контента” (Mixed Content Blocking). Для взаимодействия с web-приложением, нативное приложение должно быть безопасным.

С одной стороны, современные браузеры считают http://127.0.0.1:8000/ “потенциально заслуживающим доверие” URL-ом, потому что он локальный. Отправленный на 127.0.0.1 трафик гарантированно не уйдёт за пределы компьютера, соответственно, считается безопасным для перехвата по сети. Это означает, что если web-приложение использует HTTPS, а нативное приложение запущено на 127.0.0.1 , то обе программы могут успешно взаимодействовать по XHR. С другой стороны, для localhost это ещё не работает. А WebSocket-ы игнорируют и 127.0.0.1 , и localhost .

Возможно, вы захотите обойти эти ограничения, настроив резолв произвольного доменного имени в глобальном DNS на адрес 127.0.0.1 (например, localhost.example.com ), выпустив сертификат для этого домена, распространяя сертификат и соответствующий ему закрытый ключ внутри нативного приложения, и настроив взаимодействие по https://localhost.example.com:8000/ вместо http://127.0.0.1:8000/ . Не делайте этого! Это подвергнет пользователей риску, и сертификат может быть отозван.

Используя доменное имя вместо IP-адреса, вы позволяете злоумышленникам запустить атаку Man in the Middle (MitM) в процессе поиска IP-адреса по доменному имени (DNS Lookup), и внедрить ответ, который укажет на другой IP-адрес. Атакующий может притвориться нативным приложением, подделывая запросы к web-приложению, что скомпрометирует аккаунт в web-приложении.

Успех атаки MitM возможен потому, что вы вынуждены распространять закрытый ключ для сертификата вместе с нативным приложением. Соответственно, любой, кто скачает это приложение, получит копию ключа. Этим вы скомпрометируете закрытый ключ, и Удостоверяющий Центр (УЦ) отзовёт сертификат, как только узнает об этом. У множества нативных приложений были отозваны сертификаты по причине распространения закрытых ключей.

К сожалению, это сужает список безопасных способов взаимодействия нативных и web-приложений. И ситуация может ещё больше усложниться в недалёком будущем, если браузеры продолжат затруднять доступ к localhost.

Так же нужно отметить, что web-сервисы с доступом к нативному API изначально небезопасны, потому что сайты, которые вы не намеревались авторизовать, могут получить доступ к этому API. Если решите углубиться в изучение проблемы, обратите внимание на Cross-Origin Resource Sharing, использование заголовка ответа Access-Control-Allow-Origin, и надёжного HTTP-парсера. Потому как даже серверы, не прошедшие подтверждение, могут посылать предварительные запросы, эксплуатирующие уязвимости в HTTP-парсере.

Создание и поверка собственных сертификатов

Любой может выпустить собственный сертификат без обращения к УЦ. Единственное различие будет в том, что выпущенные вами сертификаты не будут приниматься кем-либо ещё. Для локальной разработки этого достаточно.

Простейший способ сгенерировать закрытый ключ и самоподписанный сертификат для localhost — выполнить следующую команду из пакета openssl:

Вы можете сконфигурировать локальный web-сервер, используя файлы localhost.crt и localhost.key, добавив localhost.crt в список доверенных корневых сертификатов.

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

Также, вы можете использовать доменное имя с точками внутри (например, www.localhost ), добавив в файл /etc/hosts как алиас адреса 127.0.0.1 . Этот подход чуть изменит способ обработки браузерами хранилища для cookie.

  • GitHub
  • Twitter

Let’s Encrypt — это бесплатный, автоматизированный и открытый Центр Сертификации, созданный для вас некоммерческой организацией Internet Security Research Group (ISRG).

Самоподписанный ssl сертификат для ip адреса

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

IntranetSSL

Решение для защиты внутренних серверов, приложений и IP-адресов

  • Обзор
  • IntranetSSL
  • CloudSSL
  • Купить

Сертификаты SSL/TLS для внутренних имен серверов, зарезервированных IP-адресов и доменных имен

IntranetSSL предлагает экономичное решение для защиты внутренних серверов, приложений и IP-адресов, для которых не требуется публичное доверие, но будет полезным шифрование SSL/TLS. Используя сертификат IntranetSSL, организация получит такой же уровень защиты и возможностей, как и при использовании публичного доверенного SSL-сертификата, но эти сертификаты выдаются удостоверяющими центрами сертификации GlobalSign, не являющимися публично доступными. IntranetSSL можно получить прямо через портал управления сертификатами GlobalSign.

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

Начиная с 1 ноября 2015 года Форум CA/B запрещает использование внутренних имен серверов и зарезервированных IP-адресов в публичных доверенных SSL-сертификатах. Это значит, что SSL сертификаты, полученные от публичного центра сертификации (например, GlobalSign), вы не сможете использовать для имен внутренних серверов. IntranetSSL от GlobalSign позволяет предприятиям продолжать выдавать SSL для имен внутренних серверов и зарезервированных IP-адресов без необходимости запуска собственного ЦС или использования самоподписанных сертификатов, поскольку сертификаты выдаются с помощью непубличных ЦС GlobalSign.

Для чего нужны сертификаты IntranetSSL?

Если вам нужны сертификаты для включения имен внутренних серверов или зарезервированных IP-адресов (поскольку они запрещены для публично доверенных сертификатов в CA/Browser Forum), но вы не хотите создавать свой собственный центр сертификации или использовать самоподписанные сертификаты

Если у вас есть сервера внутри локальной сети, которые не нуждаются в публичном доверии, IntranetSSL является наиболее экономичным вариантом для их защиты

Если вам нужно выдавать сертификаты, которые недопустимы в публичных иерархиях, например, с алгоритмом SHA-1 или сроком действия 3-5 лет

Если вы не хотите, чтобы имена ваших внутренних серверов отображались в логах публичной системы мониторинга прозрачности сертификатов (CT)

Если вы хотите управлять всеми своими сертификатами, как публичными, так и приватными, из единого места, то IntranetSSL позволяет использовать сертифицированные WebTrust инфраструктуру и инструменты управления GlobalSign для обнаружения, отслеживания, отчетов и управления всеми сертификатами в динамично изменяющейся серверной среде

Ключевые особенности сертификатов IntranetSSL

  • Защита с помощью иерархий RSA 2048 бит и ECC 256 бит
  • Гибкий выбор алгоритмов подписи: SHA-1 или SHA-256 или ECDSA
  • Защита до 500 альтернативных имен, в том числе имен серверов, доменных имен, поддоменов, wildcard и IP-адресов
  • Опция лицензирования SAN добавляет поддержку ограниченного числа альтернативных имен, позволяя выпускать временный сертификат или сертификат с коротким периодом действия без изменения базовых условий
  • Мгновенная выдача с помощью платформы по управлению сертификатами GlobalSign
  • Поддержка более длительного периода действия сертификата, чем допустимо в публичных иерархиях (до 5 лет)
  • Многократный повторный выпуск в течение срока действия
  • Опциональная поддержка AutoCSR — мы создадим для вас ключи и CSR
  • Лицензирование неограниченного количества серверов — установка на любом количестве серверов

Как можно использовать сертификат IntranetSSL?

IntranetSSL поддерживает выдачу сертификатов SSL с внутренними именами серверов и зарезервированными IP-адресами в CN и SAN; более того, возможность смешивать и сопоставлять внутренние имена, полностью определенные имена доменов, субдомены, wildcard и глобальные IP-адреса в одном сертификате, используя один сертификат в непубличном корневом центре GlobalSign.

Локальные имена узлов (mysite.localhost)

Зарезервированные IP-адреса (192.168.0.0)

Полные доменные имена (www.mysite.com)

Общедоступные IP-адреса (128.255.0.1)

Корневой IntranetSSL

Публичные корневые сертификаты GlobalSign уже встроены в каждую операционную систему, браузер, устройство и т.п. Однако сертификаты IntranetSSL выдаются из отдельных непубличных корневых центров — так они могут содержать иные запрещенные функции, такие как поддержка внутренних имен серверов, SHA -1 для устаревших систем, срок действия более 5 лет и отсутствие необходимости публикации сертификатов в публичных логах мониторинга прозрачности сертификатов.

Для того, чтобы браузеры или межсерверные связи доверяли сертификатам IntranetSSL, необходимо дистрибутировать корневые сертификаты через групповые политики GPO или иные связанные с этим корпоративные инструменты, чтобы клиенты не получали предупреждающие сообщения. Как только это будет сделано, клиенты не заметят никакой разницы между сайтами, использующими IntranetSSL и сайтами с общедоступными SSL-сертификатами.

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

Комплексное управление сертификатами

Сертификаты IntranetSSL выпускаются непосредственно в платформе MPKI компании GlobalSign, предоставляя организациям все те же надежные функции управления жизненным циклом сертификата, что и для публичных доверенных SSL-сертификатов. Единственное отличие заключается в том, что эти сертификаты выдаются центрами сертификации GlobalSign, которые не являются публично доступными. Управляйте с единой платформы вашими публичными доверенными SSL-сертификатами и приватными доверенными SSL-сертификатами.

Преимущества управляемой платформы PKI GlobalSign:

Облачная платформа управления сертификатами сокращает затраты сил, денег
и времени на управление многочисленными SSL-сертификатами

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

Гибкие условия ведения бизнеса, в том числе оплата по мере поступления, внесение средств на счет, сертификаты или модели лицензирования SAN, устраняют необходимость приобретения и отслеживания токенов или «пакетов»

Службы OCSP с высоким уровнем нагрузки и высокой доступностью

Инструменты для локального сканирования, обнаружения и отслеживания внутренних серверов, которым требуются сертификаты IntranetSSL

Полностью автоматизированная выдача через API-интерфейсы

GlobalSign предлагает все инструменты, службы и продукты SSL, позволяющие снизить риски и реагировать на угрозы без чрезмерных расходов на SSL. Возьмите под контроль управление SL с помощью GlobalSign уже сегодня!

Далее: Cвяжитесь с нами сегодня, чтобы защитить имена внутренних серверов!

Когда бесплатное дороже платного. Почему лучше заплатить за SSL-сертификат

В статье разберём все плюсы и минусы платных и бесплатных SSL-сертификатов для вашего бизнеса.

Зачем вообще нужен SSL-сертификат

SSL-сертификат — это цифровая подпись сайта. Она обеспечивает безопасное шифрованное соединение пользователя с вашей платформой. Без такого сертификата все данные, которые вводят на сайте посетители, могут быть похищены: электронные адреса, пароли и данные банковских карт.

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

Сегодня поговорим о том, как выбрать SSL-сертификат для сайта.

Существует три способа получить сертификат:

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

Рассмотрим плюсы и минусы каждого из видов сертификатов и сделаем выводы.

Бесплатные сертификаты

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

Самоподписанный (самоизданный, самозаверенный, self-signed) сертификат — тот, который вы сами создали для своего домена или IP-адреса. Многим владельцам сайтов может показаться, что это идеальный вариант:

  • Бесплатно.
  • Доступно. Такой SSL-сертификат может создать любой владелец домена.
  • Без обращения к поставщикам услуг. Не нужно ждать ответа от центра сертификации.
  • Быстро. Но только если вы знаете, что делать и как пользоваться специальными программами или библиотеками. Например, для Windows можно воспользоваться криптографическим хранилищем OpenSSL или консолью PowerShell.
  • Можно создать сколько угодно сертификатов.

Вам уже кажется, что выбор сделан и читать дальше нет смысла? Всё не совсем так.

Минусы
  • Нет надёжной защиты. Браузеры не доверяют таким сертификатам, потому что заверяют их не специальные центры, а неизвестный им человек или юрлицо.
  • Есть риск потерять данные. Причём как пользователей, так и ваши, с сайта компании.
  • Отпугивает посетителей сайта. Пользователи, заходя на страницу с самоподписанным сертификатом, видят предупреждение о небезопасности: в результате количество посетителей сайта, готовых совершать на нем действия, снижается. Мало ли что — вдруг сайт мошеннический.
  • Возможные ошибки в оформлении и отображении сертификата, если он был создан неправильно.

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

Бесплатные доверенные сертификаты

Такие SSL-сертификаты можно оформить довольно быстро. Часто ими пользуются стартапы, чтобы понять, что вообще такое SSL и как это работает. Бывают только одного вида — DV SSL (Domain Validation). Это сертификаты, удостоверяющие доменное имя.

Где можно получить

Самые известные бесплатные сертификаты от доверенных центров предоставляют Let’s Encrypt и CloudFlare.

Плюсы
  • Бесплатно.
  • Быстро. Такой сертификат могут выдать вам уже через несколько минут. Всё потому, что тип такого сертификата — DV (Domain Validation) SSL и для его оформления нужно только подтверждение владения доменом, как и у платных DV.
  • Просто получать и устанавливать.
  • Отлично подойдёт для теста с возможностью сэкономить в первые несколько месяцев.
  • Известные компании-поставщики. Те же Let’s Encrypt на рынке с 2012 года и поддерживаются Google, Facebook и другими крупными корпорациями.
Минусы
  • Небольшой срок действия. Например, сертификаты Let`s Encrypt необходимо перевыпускать каждые 3 месяца.
  • Сложности с продлением. Хостеры автоматически продлевают некоторые бесплатные сертификаты. Но здесь бывают проблемы. Перед выпуском сертификационный центр обращается к сайту за специальным файлом. Иногда он в системе не обнаруживается: не было места на диске и файл не записался, во время проверки почему-то закрылся доступ к сайту и пр. Итог один — сертификат не обновляется, а вы даже не узнаете об этом, если не решите вдруг проверить срок действия вручную.
  • Отсутствие поддержки. Для корректной работы SSL-сертификата важна грамотная полноценная поддержка (по телефону, по email, в чатах). Она недоступна для бесплатных SSL. На официальных сайтах удостоверяющих центров, как правило, размещены ответы на часто задаваемые вопросы, которые в основном описывают общие случаи и могут быть бесполезны для решения конкретной проблемы. Также есть неофициальная информация на тематических форумах, но среди неё ещё надо найти нужную.
  • Есть вероятность не заметить, что сертификат не работает. Как мы писали выше, посмотреть сроки действия сертификата можно вручную. Есть и другой способ: проверять даты с помощью специального скрипта, который не так просто создать. Поддержки нет. Если не проверять сроки, можно пропустить время продления, и сертификаты будут аннулированы. В безопасности сайта появятся дыры, посетители, увидев уведомление о ненадёжности сайта, станут покидать сайт и трафик снизится.

В 2017 году кредитное бюро Equifax сообщило о масштабном взломе: хакеры украли данные 143 млн человек — почти половины населения США. Это произошло отчасти из-за истечения срока действия сертификата, который был неактивным в течение 19 месяцев.

  • Несовместимость с некоторыми браузерами. Как правило, такие сертификаты не могут использовать устаревшие версии браузеров и платформ. Это значит, что даже с сертификатом ваш сайт может не открыться у части клиентов. Они увидят предупреждающее об опасности окно и, скорее всего, уйдут с вашей страницы.
  • Отсутствие гарантий и компенсаций. При использовании бесплатного сертификата сертификационный центр берёт на себя ответственность за шифрование данных. Но при утечке ответственность будет на вас. Гарантии и компенсацию за взлом вы не получите.
  • Для самостоятельного выпуска и установки нужны навыки администрирования. При том, что выпустить и установить сертификат бывает не так трудно, навыки администрирования всё же пригодятся, если вы не хотите просидеть несколько часов за инструкциями.
  • Нежелательны для сайтов с платежами. Бесплатные SSL-сертификаты обычно поддерживают технологию SNI (Server Name Identification). С её помощью можно установить сразу несколько сертификатов на один IP-адрес. Иногда это и удобно, но далеко не все платёжные системы работают с такой технологией. Плюс без надёжного SSL-сертификата покупатель не поймёт, кому принадлежит сайт и куда он собирается перевести деньги. Поэтому, если вы работаете с банком, финансовыми организациями, если у вас интернет-магазин или другой сайт, который принимает электронные платежи, не экономьте на SSL-сертификате.

Платные сертификаты

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

Где можно купить

Сертификаты можно приобрести напрямую в удостоверяющих центрах: например, DigiCert, GeoTrust, Thawte — их сертификаты широко известны, узнаваемы и надежны, обеспечивают безопасность передачи данных и доверие к сайту, повышают позиции в выдаче поисковых систем. Русскоязычным пользователям, как правило, удобнее покупать SSL у российских официальных партнёров этих удостоверяющих центров. Например, у регистраторов доменов и хостинг-провайдеров. RU-CENTER всегда выбирает лучших поставщиков для своих клиентов — подходящий вариант можно выбрать в каталоге.

Основные типы

Вы можете выбрать подходящий для вашего сайта тип сертификата:

  • Для небольших интернет-проектов (личных сайтов, блогов, микробизнеса, ИП) — DV (Domain Validation) SSL. Подтверждают доменное имя, но не содержат информации о том, кому оно принадлежит. Выпускаются по результатам упрощенной автоматизированной проверки заявителя, поэтому обеспечивают базовый уровень надежности.
  • Для бизнеса — OV (Organization Validation) SSL. Удостоверяют домен и его принадлежность той или иной компании. Стандартный уровень надежности.
  • Для крупных брендов, банков и сайтов, принимающих платежи — EV (Extended Validation) SSL. Перед выпуском сертификата в отношении его будущего владельца проводится расширенная проверка, обеспечивающая максимальный уровень доверия. Такие сертификаты обладают функционалом OV, кроме того, для использующих их сайтов браузеры отображают зеленую адресную строку как дополнительный индикатор подлинности.
  • Для компаний, использующих несколько доменов или поддоменов — мультидоменные OV-сертификаты.

Плюсы

  • Удобство. Не нужно ставить напоминания и переоформлять сертификаты каждые 90 дней, как при работе с бесплатными сертификатами, и бояться истечения сроков. Обновлять платные сертификаты надо будет только раз в год.
  • Совместимость с 99% браузеров. Это значит, что большинство пользователей не получают пугающих уведомлений о ненадёжности сайта, спокойно ходят по нему, вводят свои данные и без опаски покупают ваши товары.
  • Высокий уровень защиты. Ключи платных сертификатов обычно большей длины, чем бесплатных. Это сильно затрудняет их расшифровку и сокращает до минимума количество взломов.
  • Гарантии от взлома. Платные сертификаты предполагают страховку, сумма которой зависит от вида сертификата и центра сертификации. Если ваш SSL-сертификат всё же взломают, вы получите гарантированное возмещение.
  • Меньше отказов, чем на страницах с сомнительными SSL-сертификатами. Это хорошо для SEO-продвижения.
  • Поддержка по телефону и email по вопросам установки и работы с SSL на всех этапах использования. Плюс большое количество инструкций на русском языке. Если возникнут проблемы, например, с выпуском или продлением сертификата, компания-поставщик сама свяжется с УЦ и всё решит.

Минусы

  • Это платно. Вам придётся потратить на такой сертификат примерно от 1 000 до 15 000 рублей в год, в зависимости от типа сертификата и количества доменов, которые вы захотите защитить.
  • Иногда долгое оформление. Сроки зависят от типа сертификата. DV (Domain Validation) SSL выпускаются практически моментально, если клиент быстро подтверждает данные со своей стороны. Если подтверждение затягивается, то сертификат выпускается в течение суток или нескольких дней. OV (Organization Validation) SSL — за 1–3 дня, а вот EV (Extended Validation) SSL оформляются дольше всех — от 5 дней и выше, так как нужно будет предоставить документы, подтверждающие деятельность компании.

Итоги

Как видите, минусов у бесплатных SSL-сертификатов больше, чем плюсов. Если вы хотите протестировать новую площадку или сэкономить на первых порах работы, выберите бесплатный сертификат. Но когда запустите бизнес на полную мощность, лучше выберите платный SSL. Не рискуйте безопасностью ваших пользователей, своим трафиком и прибылью.

Не забывайте, что сертификаты продают хостинг-провайдеры и регистраторы, в том числе RU-CENTER. Часто SSL бывают включены в пакет с хостингом и доменом — это позволяет сэкономить.

Создание самоподписанных сертификатов SSL для Apache в Ubuntu 20.04

TLS или протокол безопасности транспортного уровня и предшествующий ему протокол SSL используются для заключения обычного трафика в защищенную оболочку с шифрованием. Используя эту технологию, серверы могут безопасно отправлять информацию клиентам без перехвата сообщений и их прочтения третьей стороной.

В этом руководстве мы покажем, как создать и использовать самоподписанный сертификат SSL с веб-сервером Apache в Ubuntu 20.04.

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

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

Чтобы получить более подходящий для производственной среды готовый сертификат, воспользуйтесь бесплатным центром сертификации Let’s Encrypt. Чтобы узнать, как загрузить и настроить сертификат Let’s Encrypt, воспользуйтесь нашим обучающим модулем «Защита Apache с помощью Let’s Encrypt в Ubuntu 20.04».

Предварительные требования

Для прохождения этого обучающего модуля вам потребуется следующее:

  • Доступ к серверу Ubuntu 20.04 с пользователем без прав root с привилегиями sudo. Наше «Руководство по начальной настройке сервера Ubuntu 20.04» рассказывает о том, как создать такого пользователя.
  • Также вам потребуется установить Apache. Вы можете установить Apache с помощью apt . Для начала обновите локальный индекс пакетов, чтобы отразить последние обновления:

Затем установите пакет apache2 :

Если вы используете брандмауэр ufw , откройте порты http и https :

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

Шаг 1 — Активация mod_ssl

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

Активируйте mod_ssl с помощью команды a2enmod :

Перезапустите Apache для активации модуля:

Теперь модуль mod_ssl активирован и готов к использованию.

Шаг 2 – Создание сертификата SSL

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

Мы можем создать ключ SSL и файлы сертификата с помощью команды openssl :

После ввода команды откроется диалоговое окно, где вы можете ввести информацию о своем сайте. Прежде чем перейти к этому шагу, посмотрим, что делает отправляемая нами команда:

  • openssl : это инструмент командной строки, предназначенный для создания сертификатов, ключей и других файлов OpenSSL и управления ими.
  • req -x509 : указывает, что мы хотим использовать управление запросами на подписание сертификатов X.509 (CSR). X.509 — это инфраструктура открытых ключей, используемая стандартами SSL и TLS для управления ключами и сертификатами.
  • -nodes : предписывает OpenSSL пропустить опцию защиты нашего сертификата кодовой фразой. Для чтения этого файла при запуске сервера без вмешательства пользователя нам потребуется Apache. Кодовая фраза предотвратит это, поскольку в ином случае нам пришлось бы вводить ее после каждого перезапуска.
  • -days 365 : эта опция устанавливает период действия сертификата. Здесь мы устанавливаем срок действия в один год. Многие современные браузеры отклоняют любые сертификаты, срок действия которых превышает один год.
  • -newkey rsa:2048 : указывает, что мы хотим сгенерировать новый сертификат и новый ключ одновременно. Мы не создали требуемый ключ для подписи сертификата на предыдущем шаге, и поэтому нам нужно создать его вместе с сертификатом. Часть rsa:2048 предписывает создать ключ RSA длиной 2048 бит.
  • -keyout : эта строка указывает OpenSSL, где разместить генерируемый файл закрытого ключа.
  • -out : указывает OpenSSL, где разместить создаваемый сертификат.

Укажите подходящие ответы. Наиболее важная строка — это та, которая запрашивает Common Name . Вам нужно ввести имя хоста, которое вы будете использовать для доступа к серверу, или публичный IP-адрес сервера. Важно, чтобы значение в этом поле совпадало с вводимыми в адресную строку браузера данными для доступа к сайту, поскольку несоответствие приведет к дополнительным ошибкам безопасности.

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

Оба созданных вами файла будут помещены в соответствующие подкаталоги в каталоге /etc/ssl .

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

Шаг 3 — Настройка Apache для использования SSL

Мы подготовили самоподписанный сертификат и ключ, и теперь нам нужно обновить конфигурацию Apache для их использования. В Ubuntu вы можете поместить новые файлы конфигурации Apache (они должны иметь расширение .conf ) в каталог /etc/apache2/sites-available/ , и они будут загружены при следующей перезагрузке или перезапуске процесса Apache.

Для этого обучающего модуля мы создадим новый файл с минимальной конфигурацией. Если вы уже настроили Apache , и вам просто нужно добавить SSL, вы можете просто скопировать строки конфигурации, начинающиеся с SSL , и переключить порт VirtualHost с 80 на 443 . Мы займемся портом 80 на следующем шаге.)

Откройте новый файл в каталоге /etc/apache2/sites-available:

Вставьте в него следующую минимальную конфигурацию VirtualHost:

Обновите строку ServerName , указав предполагаемое имя для обращения к вашему серверу. Это может быть имя хоста, полное доменное имя или IP-адрес. Убедитесь, что выбранное имя соответствует параметру Common Name , выбранному при создании сертификата.

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

Создадим каталог DocumentRoot и поместим в него файл HTML для целей тестирования:

Откройте новый файл index.html в текстовом редакторе:

Вставьте в пустой файл следующее:

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

Сохраните и закройте файл. После этого нам нужно активировать файл конфигурации с помощью инструмента a2ensite :

Затем проверим ошибки конфигурации:

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

Первая строка — это сообщение о том, что директива ServerName не задана глобально. Если вы хотите избавиться от этого сообщения, вы можете задать для ServerName доменное имя вашего сервера или IP-адрес в каталоге /etc/apache2/apache2.conf . Это необязательно, потому что данное сообщение не наносит никакого вреда.

Если в результатах есть сообщение Syntax OK , в вашей конфигурации нет синтаксических ошибок. Мы можем безопасно перезагрузить Apache для внесения изменений:

Теперь загрузите свой сайт в браузере, добавив префикс https:// .

Вы должны увидеть сообщение об ошибке. Для самоподписанных сертификатов это нормально! Браузер предупреждает вас, что не может проверить подлинность сервера, поскольку наш сертификат не подписан известным браузеру центром сертификации. Для целей тестирования и личного использования этого достаточно. У вас должна быть возможность нажать кнопку «Дополнительно» или «Подробности» и продолжить.

После этого браузер загрузит страницу с сообщением it worked! .

Примечание. Если ваш браузер не подключается к серверу, убедитесь, что соединение не блокируется брандмауэром. Если вы используете ufw , следующие команды откроют порты 80 и 443 :

Затем мы добавим в нашу конфигурацию другой раздел VirtualHost для обслуживания простых запросов HTTP и их перенаправления в HTTPS.

Шаг 4 — Перенаправление HTTP в HTTPS

Сейчас наша конфигурация отвечает только на запросы HTTPS через порт 443 . Также рекомендуется открыть для ответов и порт 80 , даже если вы хотите принудительно шифровать весь трафик. Настроим VirtualHost для реагирования на незашифрованные запросы и их перенаправления в HTTPS.

Откройте файл конфигурации Apache, созданный нами на предыдущих шагах:

Создайте в конце файла еще один блок VirtualHost для запросов через порт 80 . Используйте директиву ServerName для привязки вашего доменного имени или IP-адреса. Затем используйте Redirect для перенаправления всех запросов на SSL VirtualHost . Не забудьте добавить косую черту в конце:

После завершения правок сохраните и закройте файл, снова протестируйте синтаксис конфигурации и перезагрузите Apache:

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

Заключение

Вы настроили Apache для обслуживания шифрованных запросов с использованием самоподписанного сертификата SSL и перенаправления нешифрованных запросов HTTP на адрес HTTPS.

Если вы планируете использовать SSL для общедоступного сайта, вам следует приобрести доменное имя и использовать широко поддерживаемый центр сертификации, например, Let’s Encrypt.

Дополнительную информацию об использовании Let’s Encrypt с Apache можно получить в обучающем модуле «Защита Apache с помощью Let’s Encrypt в Ubuntu 20.04».

Как выпустить самоподписанный SSL сертификат и заставить ваш браузер доверять ему

Все крупные сайты давно перешли на протокол https. Тенденция продолжается, и многие наши клиенты хотят, чтобы их сайт работал по защищенному протоколу. А если разрабатывается backend для мобильного приложения, то https обязателен. Например, Apple требует, чтобы обмен данными сервера с приложением велся по безопасному протоколу. Это требование введено с конца 2016 года.

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

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

Затем сам сертификат:

Нужно будет ввести страну, город, компанию и т.д. В результате получаем два файла: rootCA.key и rootCA.pem

Переходим к главному, выпуск самоподписанного сертификата. Так же как и в случае с корневым, это две команды. Но параметров у команд будет значительно больше. И нам понадобится вспомогательный конфигурационный файл. Поэтому оформим все это в виде bash скрипта create_certificate_for_domain.sh

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

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

Запросим у пользователя название домена. Добавим возможность задания “общего имени” (оно используется при формировании сертификата):

Чтобы не отвечать на вопросы в интерактивном режиме, сформируем строку с ответами. И зададим время действия сертификата:

В переменной SUBJECT перечислены все те же вопросы, который задавались при создании корневого сертификата (страна, город, компания и т.д). Все значение, кроме CN можно поменять на свое усмотрение.

Сформируем csr файл (Certificate Signing Request) на основе ключа. Подробнее о файле запроса сертификата можно почитать в этой статье.

Формируем файл сертификата. Для этого нам понадобится вспомогательный файл с настройками. В этот файл мы запишем домены, для которых будет валиден сертификат и некоторые другие настройки. Назовем его v3.ext. Обращаю ваше внимание, что это отдельный файл, а не часть bash скрипта.

Да, верно, наш сертификат будет валидным для основного домена, а также для всех поддоменов. Сохраняем указанные выше строки в файл v3.ext

Возвращаемся в наш bash скрипт. На основе вспомогательного файла v3.ext создаем временный файл с указанием нашего домена:

Переименовываем сертификат и удаляем временный файл:

Скрипт готов. Запускаем его:

Получаем два файла: mysite.localhost.crt и device.key

Теперь нужно указать web серверу пути к этим файлам. На примере nginx это будет выглядеть так:

nginx ssl

Запускаем браузер, открываем https://mysite.localhost и видим:

Браузер не доверяет этому сертификату. Как быть?

Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:

Обновляем страницу в браузере и:

Успех! Браузер доверяет нашему сертификату.

Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.

Делитесь в комментариях, используете ли вы https для локальной разработки?

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!:

Adblock
detector