самоподписанный ssl сертификат что это
Как выпустить самоподписанный 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 это будет выглядеть так:
Запускаем браузер, открываем https://mysite.localhost и видим:
Браузер не доверяет этому сертификату. Как быть?
Нужно отметить выпущенный нами сертификат как Trusted. На Linux (Ubuntu и, наверное, остальных Debian-based дистрибутивах) это можно сделать через сам браузер. В Mac OS X это можно сделать через приложение Keychain Access. Запускаем приложение и перетаскиваем в окно файл mysite.localhost.crt. Затем открываем добавленный файл и выбираем Always Trust:
Обновляем страницу в браузере и:
Успех! Браузер доверяет нашему сертификату.
Сертификатом можно поделиться с другими разработчиками, чтобы они добавили его к себе. А если вы используете Docker, то сертификат можно сохранить там. Именно так это реализовано на всех наших проектах.
Делитесь в комментариях, используете ли вы https для локальной разработки?
Максим Ковтун,
Руководитель отдела разработки
Создание самоподписанного сертификата SSL
Creating a Self-Signed SSL Certificate
В этом руководстве объясняется, как создать самозаверяющий сертификат SSL с помощью инструмента openssl.
Что такое самоподписанный сертификат SSL?
Самозаверяющие сертификаты, признанные действительными в любом браузере. Если вы используете самозаверяющий сертификат, веб-браузер покажет посетителю предупреждение о том, что сертификат веб-сайта невозможно проверить.
Самозаверяющие сертификаты в основном используются для целей тестирования или внутреннего использования. Вы не должны использовать самозаверяющий сертификат в производственных системах, которые подключены к Интернету.
Предпосылки
Инструментарий openssl необходим для создания самозаверяющего сертификата.
Если пакет openssl не установлен в вашей системе, вы можете установить его, выполнив следующую команду:
Создание самоподписанного SSL-сертификата
Чтобы создать новый самоподписанный сертификат SSL, используйте openssl req команду:
Давайте разберем команду и разберемся, что означает каждая опция:
Для получения дополнительной информации о параметрах openssl req команды посетите страницу документации OpenSSL req.
Как только вы нажмете Enter, команда сгенерирует закрытый ключ и задаст вам ряд вопросов, которые она будет использовать для генерации сертификата.
Введите запрашиваемую информацию и нажмите Enter.
Сертификат и закрытый ключ будут созданы в указанном месте. Используйте команду ls, чтобы убедиться, что файлы были созданы:
Это оно! Вы создали новый самозаверяющий сертификат SSL.
Всегда полезно создать резервную копию нового сертификата и ключа для внешнего хранилища.
Создание самоподписанного SSL-сертификата без запроса
Вывод
В этом руководстве мы показали, как создать самозаверяющий сертификат SSL с помощью инструмента openssl. Теперь, когда у вас есть сертификат, вы можете настроить приложение для его использования.
Самоподписанный ssl сертификат что это
Технически такой сертификат не отличается от версии, подписанной доверенным центром. Разница — в подписи, заверяющей сертификат.
Самозаверенные версии чаще используются для тестирования сайтов и приложений. Их также создают для небольших сайтов, которые нет смысла атаковать со стороны. Ресурсы с большой посещаемостью, а также собирающие личные данные посетителей, должны идентифицироваться исключительно доверенными сертификатами.
Самостоятельно можно создать сколько угодно самоподписанных версий. При загрузке страниц сайтов с такими сертификатами посетителям всегда будет выводиться сообщение подобного содержания:
Такое предупреждение отпугивает людей. Большинство откажутся переходить на такой сайт, в результате чего упадет его посещаемость.
Вывод здесь один: для привлечения посетителей нужно использовать доверенные сертификаты, подписанные известными центрами. Их корневые сертификаты имеются в каждом браузере, который выдает пользователю уведомление о надежности шифрования данных.
Их создают вручную с помощью специальных программ или библиотек. Например, для Windows можно воспользоваться криптографическим хранилищем OpenSSL или консолью PowerShell. Эти инструменты генерируют сертификаты SSL, создают открытые и секретные ключи.
Создание самоподписанного сертификата SSL через OpenSSL подразумевает использование таких команд:
out /home/devuser/cert/cert.crt — место локации сертификата;
newkey rsa:2048 — автоматическое создание ключа, если у вас его нет;
req-x509 — запрос на генерацию самоподписанного сертификата;
keyout /home/devuser/cert/mykey.key — запрос на генерацию ключа.
Затем после ввода пароля необходимо описать данные вашего сервера. Для пропуска определенного параметра оставьте точку «.» в конце командной строки:
Вы можете отметить в своем браузере, что созданный сертификат является безопасным. Тогда на вашем устройстве не будет выскакивать сообщение о незащищенном соединении. Все остальные пользователи по-прежнему будут получать такое сообщение.
Чтобы создать самоподписанный сертификат SSL в Windows с помощью утилиты PowerShell, введите в ней команду:
Это и есть запрос на генерацию самоподписанного сертификата. После создания вы можете переместить его в папку доверенных сертификатов на вашем компьютере. После этого браузер перестанет выдавать уведомление об отсутствии шифрования данных.
Так выглядит самоподписанный сертификат SSL на сервере Nginx:
Где cert.crt означает открытый ключ, а cert.key — секретный ключ.
Самоподписанный сертификат на сервере Apache выглядит так:
Доверенные центры выдают разные формы сертификатов, которые разнятся между собой по стоимости. Самый простой означает проверку подлинности доменного имени.
Более дорогой выдается после полноценной проверки данных, предоставляемых компанией. Вплоть до того, что могут проверить контакты и документацию заявителя.
После успешной идентификации на сайте появляется соответствующий зеленый значок с логотипом центра. Этот фактор сильно влияет на доверие посетителей к сайту.
Сходство между самоподписанным сертификатом и доверенным заканчивается на их технической части. Самозаверенный сертификат создает шифрование данных, передаваемых от браузера к серверу.
Тем не менее, эта информация находится под угрозой захвата третьими лицами и не может быть отозвана. К тому же, на сайте, идентифицированном самоподписанным SSL-сертификатом, всегда будет выскакивать уведомление об опасном соединении. Этот фактор влияет на его посещаемость.
Использовать самописные сертификаты лучше на небольших сайтах, в тестируемых приложениях или внутренних ресурсах малых фирм, где о небезопасном соединении известно всем сотрудникам. Коммерческие ресурсы с высокой посещаемостью должны идентифицироваться исключительно доверенными центрами сертификации.
Хотите узнать как быстро проверить свой сайт на ошибки ?
Оставьте свой email, перейдя по ссылке, и вы получите whitepaper с пошаговым руководством по почте.
Сэкономьте время на изучении Serpstat
Хотите получить персональную демонстрацию сервиса, тестовый период или эффективные кейсы использования Serpstat?
О самоподписных сертификатах
я не доверяю вашому самоподписному сертификату, почему вы не купите «нормальный» сертификат?
Как по мне, это один из случаев недопонимания и предрассудков, которых так много в отношении безопасности в Интернете. (Вроде знаменитых «Хакеров, крекеров, спамов, куки» :). Хочу разобрать его с двух точек зрения: как человека, некоторое время проработавшего в сфере защиты информации в банке и имевшего дело с большинством аспектов информационной безопасности, и как человека, занимающегося разработкой и развитием интернет-сервиса.
Но сперва отвечу на вопрос, почему у нас нет «нормального» сертификата? (На самом деле, с недавнего времени есть 🙂 Самая главная причина в том, что в нашем списке приоритетов этот пункт стоял на N-ном месте, и только сейчас все N-1 предыдущих пунктов были выполнены. Когда работаешь над новым проектом, всегда приходится от чего-то отказываться, потому что ресурсы, прежде всего временные, ограничены…
… Если же сертификат выдан каким-нибудь Verisign-ом (для примера), то это некая «гарантия» что за этим сайтом стоит настоящая организация/частное лицо и уж как минимум «есть с кого спросить в случае чего». Т.е. вообще это как гарантия «серьезности» намерений владельцев сайта.
Мы прекрасно понимаем, что такое мнение имеет право на жизнь. Но ведь все не так просто. Ничто не мешает купить сертификат у Verisign или другого вендора на липовую контору или подставные личные данные. Они не могут проверить наличие у клиента юридических оснований выдавать себя за условные ООО «Рога и копыта» из г.Пермь, Россйская Федерация. Единственное, что проверяется при выпуске сертификата — это то, принадлежит ли вам домен, для которого вы его запрашиваете.
Так что, как по мне, покупка сертфиката у Verisign’а — это всего-навсего демонстрация того, что компания готова выбросить 500$ и несколько человеко-часов, а то и больше на утрясение всех организационных вопросов, вместо того, чтобы потратить это время и деньги на разработку новых возможностей или же реальное улучшение безопасности системы. Вообще, Verisign — это для банков. Есть другие вендоры, с которыми проще и дешевле (пример — ниже).
Еще один аспект безопасности, связанный с сертификатами. Будь он самоподписным или выданным Verisign’ом, все равно с ним ассоциирован секретный ключ, который нужно где-то хранить. Более того, он постоянно используется веб-сервером при открытии HTTPS-соединений, т.е. его нельзя применить один раз при включнии питания, сохранить на флешку и спрятать в сейф. Что будет, если кто-то завладеет ключом? (программист, который имел доступ к серверу, взломщик или еще кто-то). В идеале, этот ключ зашифрован, но при желании и наличии ресурсов его можно расшифровать (и сейчас это дешевле, чем организовать фишинг-атаку). А ведь мы не учли, что некоторые веб-сервера или реверс-прокси вообще не умеют работать с зашифрованными ключами. А еще ведь пароль может быть захардкожен где-то в тексте программы или скрипта, который ее запускает… Так что то, что на каком-то сайте красуется бирочка, что его SSL сертификат подписан Verisign, не дает никакой гарантии, что в один прекрасный день не появится фарминг-аналог, использующий тот же сертификат с украденным секретным ключом.
Тут я даже не вспоминаю о таких аспектах, связанных с системой PKI, как особенности ее поддержки на разных специфических платформах, таких как j2me…
Резюме: есть вещи, которые, в целом, правильные, но не всегда стоят затраченных усилий. Концентрация стартапов должна быть на другом, а мелочи, подобные «правильным» сертификатам должны идти вторым эшелоном. Сначала, как говорят американцы, нужно «get the product right». Всему свое время.
Обзор SSL-сертификатов: типы, выбор, приемущества.
Многие задавали себе вопрос, чем различаются разные SSL-сертификаты, зачем его получать и почему нельзя использовать самоподписанный.
Здесь я попытаюсь ответить на эти вопросы, рассмотрев:
Я не претендую за 100% верность данной статьи, она основана только на моем мнении и личном опыте 🙂
SSL — Secure Sockets Layer — стандарт передачи защифрованных данных через сеть. Касательно web-индустрии это протокол HTTPS.
О сертификатах вообще и зачем их нужно подписывать.
Здесь и далее речь пойдет приемущественно о web-сайтах. Вопросы SSL + FTP, Email, цифровых подписей исходного кода и пр. до поры оставим в стороне.
SSL-сертификат, это индивидуальная цифровая подпись вашего домена. Он может быть:
Разберем их более подробно.
Самоподписанный сертификат не гарантирует ничего. Любой человек может взять и выдать себе такой сертификат. Все браузеры выдают клиенту предпреждение о том, что сертификат не надежен.
Подписанный не доверенным ЦС сертификат тоже не подтверждает ничего, т.к. существуют ЦС, продающие сертификаты всем желающим и без проверок. Большинство браузеров реагирует на такие сертификаты аналогично самоподписанным.
Сертификат, подписанный доверенным источником (как пример — Thawte или VerySign) подтверждает, что:
На доверенные сертификаты браузеры ошибку не выдают.
Но это технически. А теперь о том, что показывает доверенный сертификат посетителю вашего сайта.
Многих пользователей (особенно зарубежных — наши пока к этому не привыкли) самоподписанный сертификат (или отсутствие SSL в вещах, касающихся услуг\финансов\privacy) может если и не отпугнуть, то поставить жирный минус в вашу пользу.
Мой личный вывод: на всех сайтах, связанных с онлайн-коммерцией, платежами, личной информацией SSL должен быть.
Типы сертификатов.
Допустим, руководствуясь соображениями из 1 части статьи вы решили купить подписанный сертификат. Каково же будет ваше удивление, когда на сайте ЦС вы узнаеете, что они бывают разные 🙂
Esential SSL — самый не дорогой и быстро оформляемый сертификат. Доступен как для юридических, так и для физических лиц. Проверяется только право владения доменным именем, личные данные или регистрация компании не проверяются. Выдается на 1 домен.
Instant SSL — доступен и для физ. лиц, и для юр. лиц. Проверяется право владения доменом, регистрационные данные компании либо личность физ. лица. Выдается на 1 домен.
SGC SSL-сертификат. — Аналогично Instant SSL, но с поддержкой 40-битных расширений (актуально для старых ОС и браузеров). Выдается на 1 домен, либо wildcard (см. ниже).
Обычный Wildcard. — тоже самое, что и обычный сертификат, но выдается не на 1 домен, а на все поддомены корневого домена. Т.е. не только на domain.com, a и на www.domain.com, bill.domain.com и т.д. Стоит на порядок дороже.
EV (Extended Validation) сертификат. — сертификат расширенной проверки, доступен только юридическим лицам. Проверяется владение доменом, компания, нотариально заверенные переводы документов на английский язык, требует подтверждения данных третьей стороной. Позволяет установить на сайте картинку-подтверждение владением и отображается в браузерах как гарантированно доверенный (зеленым цветом), против желтого у обычных сертификатов. Стоит в 2-3 раза дороже обычного, регистрация занимает продолжительное время.
В браузере выглядит так:
EV Wildcard и EV SGC. — аналогично Wildcard и SGC, но с расширенной проверкой.
Instant и Essential сертификаты позиционируются как продукт для сайтов частных лиц и органзаций, не связанных с электронной коммерцией.
Extended Validation — для сайтов, связанных с финансами, услугами (интернет-банкинг, платежные системы, интернет-магазины и пр.).
В следующей статье я напишу, как выбрать регистратора и получить сертификат.