Что такое самоподписанный сертификат
Как выпустить самоподписанный 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 для локальной разработки?
Максим Ковтун,
Руководитель отдела разработки
Что такое самоподписанный сертификат
Технически такой сертификат не отличается от версии, подписанной доверенным центром. Разница — в подписи, заверяющей сертификат.
Самозаверенные версии чаще используются для тестирования сайтов и приложений. Их также создают для небольших сайтов, которые нет смысла атаковать со стороны. Ресурсы с большой посещаемостью, а также собирающие личные данные посетителей, должны идентифицироваться исключительно доверенными сертификатами.
Самостоятельно можно создать сколько угодно самоподписанных версий. При загрузке страниц сайтов с такими сертификатами посетителям всегда будет выводиться сообщение подобного содержания:
Такое предупреждение отпугивает людей. Большинство откажутся переходить на такой сайт, в результате чего упадет его посещаемость.
Вывод здесь один: для привлечения посетителей нужно использовать доверенные сертификаты, подписанные известными центрами. Их корневые сертификаты имеются в каждом браузере, который выдает пользователю уведомление о надежности шифрования данных.
Их создают вручную с помощью специальных программ или библиотек. Например, для 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?
Главные минусы самоподписанных SSL-сертификатов
SSL-сертификаты — самый распространенный тип сертификатов в Интернете. Чаще всего их устанавливают на сайтах, которые собирают персональные данные пользователей (email, пароли, данные банковских карт и др.). Чтобы эти данные не перехватили, соединение защищается специальным протоколом HTTPS, шифрующим всю информацию, которой обмениваются посетитель и сайт. Для работы этого протокола как раз и нужны SSL-сертификаты, приставка SSL (Secure Socket Layer) в названии которых — это технология, обеспечивающая шифрование соединения между веб-сервером (сайтом) и браузером.
Когда сайт работает по защищенному протоколу HTTPS браузер сообщает об этом пользователю в адресной строке. Например, в браузере Google Chrome отображается замок зеленого цвета и надпись Secure (безопасный):
А при желании пользователь может посмотреть сведения о сертификате, кликнув на замок правой кнопкой мышки:
В сертификате хранится следующая информация:
Цифровая подпись, заверенная центром сертификации, является доказательством подлинности владельца домена и обуславливает его право законно использовать секретный ключ.
Сами же SSL-сертификаты делятся на несколько типов. В самых простых проверяется только домен, в самых дорогих — производится целый ряд проверок, а название организации отображается в адресной строке рядом с доменом.
Доверенные и недоверенные сертификаты
Выпуском SSL-сертификатов занимаются центры сертификации или, как их еще называют, удостоверяющие центы (Certification Authority, CA). Как правило, это авторитетные IT-организации, пользующиеся известным открытым криптографическим ключом:
Сертификаты этих организаций называют доверенными. К недоверенным же сертификатам относятся:
Почему не стоит пользоваться самоподписанными сертификатами?
Когда к сайту, защищенному самоподписанным сертификатом, подключается пользователь, он видит предупреждение о том, что сертификат не является безопасным:
Большинство посетителей предпочтет не переходить на такой сайт, а его владелец может потерять значительную аудиторию. Поэтому на публичных сайтах и тем более в онлайн-магазинах ни в коем случае нельзя использовать самоподписанные SSL-сертификаты.
Вторая угроза самоподписанных сертификатов — это атаки. Дело в том, что такими сертификатами любят пользоваться хакеры, совершая фишинговые атаки. При фишинге пользователей перенаправляют на сайт с похожим адресом (URL). При этом в браузере обязательно появится предупреждение про небезопасный сертификат (точно такое же, как при входе на реальный сайт с самоподписанным сертификатом).
В итоге у самоподписанного сертификата можно разглядеть только одно достоинство — бесплатность. Но и этому найдется альтернатива в виде SSL-сертификатов проверенных центров сертификации, которые тоже выпускаются бесплатно. Например, сертификаты Let’s Encrypt. Однако не стоит забывать и про недостатки Let’s Encrypt:
Поэтому рекомендуем вам обратить внимание на платные сертификаты проверенных брендов. Например, облачные провайдеры VPS/VDS или IaaS часто предлагают приобрести надежные SSL-сертификаты вместе с услугой хостинга, причем стоимость такого сертификата будет намного ниже, чем при его приобретении непосредственно у центров сертификации.
Всё о SSL-сертификатах простыми словами: устройство, типы, выбор
Если вы уже сталкивались с созданием собственного сайта, то наверняка краем уха слышали про сертификат SSL и HTTPS — поэтому в нашем новом посте расскажем, как защитить данные посетителей сайта, чем HTTPS отличается от HTTP, что такое SSL-сертификат и какие виды сертификатов существуют?
Что такое SSL-сертификат
SSL (Secure Sockets Layer — уровень защищённых сокетов) — это протокол шифрования, который позволяет кодировать данные для более безопасного обмена.
Проще говоря, сертификат обеспечивает зашифрованное соединение между человеком и используемым сайтом. Когда вы смотрите видео на YouTube, загружаете фотографию в Facebook или открываете Instagram, ваш браузер и сервер обмениваются информацией.
Благодаря SSL информация, которая передаётся, защищена от посторонних: администратора Wi-Fi сети, провайдера, оператора и других лиц — значит она не может быть перехвачена и использована в мошеннических целях. Кроме того, SSL-сертификат выступает в качестве подтверждения надёжности ресурса и даёт возможность проверить, кто является его настоящим владельцем.
Можно сказать, что SSL-сертификат — это своего рода уникальная цифровая подпись сайта.
Такой сертификат нужен всем сайтам, которые в каком-либо виде работают с персональными данными пользователей: от логинов и паролей до более подробных. В первую очередь это, конечно, банки, платёжные системы, интернет-магазины и коммерческие платформы.
Проверить наличие SSL несложно. Для этого достаточно посмотреть на адресную строку в браузере. Слева от адреса сайта вы увидите значок с изображением закрытого замка.
А если на сайт установлен OV или EV сертификат, то при клике на замочек, появятся данные об организации, которой принадлежит сайт.
В таких типах сертификатов во вкладке «Подробнее» вы найдёте следующую информацию:
Разница между HTTP и HTTPS
Как вы уже знаете, каждый вбитый в поисковую строку запрос проходит путь от вас (пользователя) к серверу и обратно. Такая коммуникация возможна благодаря работе протокола HTTP. Аббревиатура расшифровывается как Hypertext Transfer Protocol. И всем он хорош — только данные не шифрует, а значит злоумышленники могут перехватить вашу личную информацию (данные банковских карт, пароли, реквизиты).
Для безопасности данных был внедрён протокол HTTPS — HyperText Transfer Protocol Secure (то есть защищённый протокол HTTP). В этом случае передача данных осуществляется по такому же протоколу, но с криптографическим шифрованием, о чём говорит дополнительная буква «S». HTTPS работает благодаря SSL/TLS-сертификату.
SSL/TLS-сертификат ― это цифровая подпись сайта. С её помощью подтверждается его подлинность.
Перед тем как установить защищённое соединение, браузер запрашивает этот SSL-сертификат и обращается к центру сертификации, чтобы подтвердить легальность документа. Если он действителен, то браузер и сервер доверяют друг другу и договариваются о разовом шифре. Так происходит каждую сессию, то есть каждый раз при обмене запросами и ответами. Вот откуда взялась и что означает «S» в HTTPS.
Каким сайтам нужен SSL?
SSL-сертификат необходимо подключать к сайтам, которые работают с финансами и персональными данными пользователей. Это интернет-магазины, банки, платёжные системы, социальные сети, почтовые сервисы и любые другие проекты.
SSL-сертификат лучше ставить с самого начала, чтобы иметь более высокие позиции в поисковых системах. Если всё же изначально не использовался сертификат, то переехать можно быстро, а вот поисковики могут увидеть это только спустя пару месяцев. Тем более сегодня поставить SSL можно и бесплатно.
Какие виды SSL-сертификатов есть и кто их выдаёт?
Есть специальные центры сертификации или как ещё называют — удостоверяющие центры (УЦ). Вы могли встречать названия таких УЦ: Symantec, Comodo, GlobalSign, Thawte, GeoTrust, DigiCert. Они подтверждают подлинность ключей шифрования с помощью сертификатов электронной подписи.
Кроме того, есть проекты, CloudFlare или LetsEncrypt, где можно получить сертификат бесплатно и самостоятельно. Такой сертификат выпускается на 3 месяца и далее требует продления. Однако во время их установки и дальнейшей работы есть ряд нюансов, которые стоит учитывать. Например, при выборе сертификата Cloudflare учтите, что он выдаётся сразу на 50 сайтов. Тем самым сертификат будет защищать не только ваш домен, но и ещё несколько чужих, что несёт за собой риски безопасности. Также у Cloudflare нет печати доверия. Если говорить о недостатках LetsEncrypt, то сюда можно отнести поддержку далеко не всех браузеров, отсутствие гарантии сохранности данных сайта и печати доверия.
Печать доверия — это особый знак, позволяющий посетителям видеть, что соединение с вашим сайтом и все передаваемые данные надёжно защищены.
Итак, существует несколько типов SSL-сертификатов по источнику подписи и типу проверки данных.
Так вот, разница между самоподписанными сертифкатами и, выданными УЦ, как раз и заключается в том, что браузер знаком с УЦ и доверяет ему, и при использовании такого сертификата ваш посетитель никогда не увидит огромное уведомление о небезопасности ресурса. Купить такой SSL-сертификат можно как напрямую в УЦ, так и через хостинг-провайдеров.
Подписанные доверенным центром сертификаты, в свою очередь, тоже подразделяются по типу проверки данных:
Сертификаты всех указанных типов обеспечивают шифрование трафика между сайтом и браузером. Кроме того, у них есть дополнительные опции:
Какой SSL-сертификат выбрать?
Итак, мы определились с тем, что SSL-сертификаты различаются между собой не только брендом и ценой. Сегодняшний ассортимент предложений предусматривает широкий круг задач, для которых может потребоваться SSL.
Например, если вы просто хотите уберечь пользователей вашего веб-сайта от навязчивых предупреждений браузера о посещении непроверенного сайта, будет достаточно за несколько минут получить простой DV (Domain Validation) сертификат. Если же вы используете свою интернет-площадку для операций, требующих повышенного уровня безопасности данных компании и клиентов — стоит задуматься об EV (Extended Validation) сертификате. А если вы используете не один, а несколько веб-адресов для сайта или сайтов компании — для вас на рынке представлены сертификаты Wildcard и SAN.
Для выбора оптимального сертификата для определённого сайта нужно изучить, что предлагают центры сертификации, обращая внимание на следующие аспекты:
4 причины установить SSL-сертификат
Безопасность данных
Конечно же, стоит начать с этого пункта, ведь в этом заключается основная цель использования SSL-сертификатов. Если вы работаете с персональными данными пользователей, вам просто необходимо их шифровать при передаче к серверу. Само по себе использование сертификата не лекарство от всех бед, злоумышленники могут перехватить данные ещё до момента передачи их на сервер на заражённом компьютере или устройстве посетителя сайта. Однако использование протокола шифрования — значительный вклад в снижение уязвимости сайта.
Доверие к сайту
Пользователи привыкают, что все крупные проекты используют SSL-сертификаты. Надпись «Защищено» и замочек дают посетителю сайта представление о том, что он и его данные находятся в безопасности.
Поддержка сторонних сервисов
Некоторые платёжные системы (Яндекс.Деньги) и сервисы (Голосовой помощник Google Chrome) работают только с сайтами с HTTPS протоколом. Если специфика вашей работы подразумевает взаимодействие с аналогичными сервисами, рекомендуем вам установить SSL-сертификат.
Фактор ранжирования
Google не раз заявлял, что поддержка HTTPS протокола станет одним из факторов ранжирования. Для Яндекса сайты по HTTP и HTTPS протоколам участвуют в ранжировании на равных, однако, поисковик обозначает, что подключать SSL стоит, если на сайте можно совершать покупки и другие финансовые операции.
SSL-сертификат от авторитетного УЦ говорит о надёжной защите пользовательских данных — это не только хороший способ заслужить доверие пользователей и поисковых систем, но и большой вклад в стабильное продвижение и развитие сайта.
Основы HTTPS, TLS, SSL. Создание собственных X.509 сертификатов. Пример настройки TLSv1.2 в Spring Boot
Привет, Хабр! В современном мире абсолютное большинство сайтов используют HTTPS (Google даже снижает рейтинг сайтов работающих по HTTP в поисковой выдаче), а подключение к различным системам происходит по протоколу TLS/SSL. Поэтому любой разработчик рано или поздно сталкивается с этими технологиями на практике. Данная статья призвана помочь разобраться, если вы совершенно не в курсе что это такое и как оно устроено. Мы разберем как работает соединение по протоколу TLS, как выпустить собственные сертификаты и настроем TLS в Spring Boot приложении. Поехали!
Что не так с HTTP?
Симметричное шифрование предполагает наличие общего ключа одновременно у отправителя и получателя, с помощью которого происходит шифровка и дешифровка данных. Данный тип не требователен к ресурсам, однако существенно страдает безопасность из-за опасности кражи ключа злоумышленником.
При использовании ассиметричного шифрования существует открытый ключ, который можно свободно распространять, и закрытый ключ, который держится в секрете у одной из сторон. Этот тип работает медленно, относительно симметричного шифрования, однако скомпрометировать закрытый ключ сложнее.
Что происходит на практике
Что такое Message Authentication Code или MAC? Это хэш, сгенерированный с использованием выбранной криптографической хэш-функции и разделяемого ключа, который добавляется сзади к сообщению. Перед отправкой данных отправитель вычисляет MAC для них, а получатель перед обработкой вычисляет MAC для принятого сообщения и сравнивает его с MAC этого принятого сообщения. Предназначен для проверки целостности, то есть что сообщение не было изменено при его передаче.
Для чего нужен идентификатор сессии? Как мы посмотрим далее, процесс установления TLS соединения затратен по времени и ресурсам. Предусмотрен механизм возобновления соединения с помощью отправки клиентом этого идентификатора. Если сервер тоже все еще хранит соответствующие настройки, то клиент и сервер смогут продолжить общение использую ранее выбранные алгоритмы и ключи.
Кем подписан сертификат корневого CA? А никем, нет инстанции выше корневого CA. Сертификат (открытый ключ) в этом случае подписан собственным закрытым ключом. Такие сертификаты называют самоподписанные (sefl-signed).
Сервер случайно генерирует число 6, передает клиенту числа p = 17, g = 3, Ys = 3 6 mod 17 = 15
Клиент случайно генерирует число 7 и возвращает серверу Yc = 3 7 mod 17 = 11
Сервер считает итоговое число 11 6 mod 17= 8, и клиент 15 7 mod 17 = 8
После этого соединение считается установленным, и происходит передача полезной информации
Двусторонний TLS
Двусторонний TLS или Two Way TLS или mutual TLS (mTLS) означает проверку сертификата клиента. Сервер после своего сообщения Certificate посылает запрос сертификата клиента CertificateRequest. Клиент в ответ отправляет Certificate, сервер производит проверку, аналогичную проверке сертификата сервера клиентом. Далее настройка TLS происходит в описанном выше порядке.
TLSv1.3
Стоит отметить, что все выше написанное относится к TLSv1.2, которая начинает понемногу устаревать. В 2018 году была разработана новая версия 1.3 в которой: были запрещены уже ненадежные алгоритмы, ускорен процесс соединения, переработан протокол рукопожатия и др. Интернет медленно но верно обновляется до TLSv1.3, однако все еще большинство сайтов работают по протоколу TLSv1.2. Поэтому информация в этой статье остается актуальной.
Выпускаем собственные сертификаты
Теперь, когда мы разобрали теорию, самое время приступить к практике! Нам понадобятся OpenSSL и keytool (входит в поставку JDK). Для начала создадим сертификат корневого CA, которым будем подписывать запросы на подпись сертификата клиента и сервера. Сгенерируем приватный ключ RSA зашифрованный AES 256 с паролем «password» длиной 4096 бит (меньше 1024 считается ненадежным) в файл CA-private-key.key:
Нет какого-то принятого стандарта расширений для файлов, связанных с сертификатами. Мы будем использовать:
Так как подписать сертификат другим сертификатом пока нельзя, подпишем запрос его же приватным ключом. Получившейся сертификат CA-self-signed-certificate.pem будет самоподписанным со сроком действия 1 день.
Теперь у нас есть сертификат, которому в будущем будут доверять наши клиент и сервер. Похожим образом сделаем приватные ключи и запросы на подпись сертификата для них:
После этого необходимо создать хранилище ключей с сертификатами (keystore) Server-keystore.p12 для использования в нашем приложении. Положим туда сертификат сервера, приватный ключ сервера и защитим хранилище паролем «password»:
Осталось только создать хранилище доверенных сертификатов (truststore): сервер будет доверять всем клиентам, в цепочке подписания которых есть сертификат из truststore. К сожалению, для Java сертификаты в truststore должны содержать специальный object identifier, а OpenSSL пока не поддерживает их добавление. Поэтому здесь мы прибегнем к поставляемому вместе с JDK keytool:
Для удобства, все описанные выше действия упакованы в bash script.
Настройка TLS в Spring Boot приложении
Основой для нашего проекта послужит шаблон с https://start.spring.io/ с одной лишь зависимостью Spring Web. Для включения TLS указываем в application.properties:
После этого указываем Spring тип keystore, путь к нему и пароль:
Для проверки доступа создадим минимальный контроллер:
Запускаем проект. Попробуем сделать запрос с помощью curl:
На этот раз все сработало, TLS в Spring Boot работает! Мы на этом не остановимся, добавим в приложение аутентификацию клиента (указываем truststore):
Запускаем и снова пытаемся выполнить запрос:
Очевидно, что сервер закрыл соединение, так как curl не предоставил никакого сертификата. Дополним запрос клиентским сертификатом и его закрытым ключом:
Итоги
В данной статье мы разобрались как работает протокол TLS и для чего он нужен. На практике научились создавать собственные сертификаты и использовать их в Java приложении на Spring Boot. Надеюсь, представленная информация оказалась Вам полезной. Спасибо за внимание!