Что нужно чтобы получить? А что это значит – SSL? Просмотр информации о сертификате

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

SSL сертификат что это простыми словами

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

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

Тогда 137 будет означать, что расположение слова приходится на первую страницу, третью строку и седьмое слово. Если получателю отправить «137-536-9978», то придется взять книгу Стругацких и начать расшифровывать, но в обратной последовательности. Если есть вероятность перехвата такого письма, то никто не сможет понять, что там написано. Это потому, что перехватчик не в курсе, какую книгу мы берем за основу шифрования.

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

А что такое SSL сертификат, и что с ним делать – это мы обсудим ниже.

Значение SSL сертификатов

Многие не знают, зачем нужен SSL сертификат сайту. Его наличие принесет огромную выгоду: сохраняя под защитойвводимые личные данные:

• пароль и логин для входа в аккаунт;
• номер карты банка;
• адрес электронной почты;
• контактный телефон.

Его установка будет важна для сайтов крупных компаний, финансовых организаций, систем для проведения платежей, интернет-магазинов, соцсетей, государственных организаций и так далее.

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

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

Разобравшись для чего необходим SSL сертификат, поговорим о его видах и особенностях.

Разновидность

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

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

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

Разновидности сертификатов

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

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

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

Получить такой SSL сертификат для сайта можно после проверки сертификационным центром прав на домен и регистрацию организации. Срок проверки занимает 1-3 дня.

Для большого бизнеса – государственная организация, банки, крупные магазины и центры требуются дополнительные проверки. Особенно, если происходит хранение ценных документов, крупных денег и данные платежных систем. Расширенная проверка занимает около 2 недель.

Несколько доменов. Установка мультидоменного типа нужна для почтовых серверов, холдингов, торговых сетей. Пользуясь одним SSL сертификатом, можно защищать до 100 доменов одновременно.

Что будет если не продлить SSL сертификат? Влияет ли эта ошибка на поведение ваших пользователей?

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

Они получают довольно пугающее предупреждение:

Вы бы продолжили, если бы увидели такое сообщение при попытке входа?

Но исследование SEO-компании "Hallam Internet", показало, что посещения на сайт почти не изменились и показатели отказов, что логично, тоже.

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

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

Бимал Шах, Айя Загуль, IBM

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

Протокол SSL (Secure Socket Layers - протокол защищенных сокетов), совместно разработанный Netscape Communications и RSA Data Security, позволяет эффективно обеспечить такую безопасность. Протокол SSL обеспечивает безопасность, аутентификацию на базе сертификатов и согласование безопасности по установленному сетевому соединению, поэтому множество компаний и продуктов приняли SSL в качестве коммуникационного протокола.

В этой серии мы сконцентрируемся на двух главных аспектах:

1. подробная информация о схеме работы SSL;
2. детальная информация о поддержке SSL в версиях 5.1 и 6.0.1 среды ISC.

В данной статье исследуется SSL и объясняется, почему его рекомендуется реализовать в среде ISC. Во второй и третьей частях этой серии будет представлена подробная пошаговая инструкция по реализации и подключению SSL к ISC 5.1 и 6.0.1.

Реализация протокола SSL, используемая в WebSphere® Application Server, хранит персональные сертификаты в файле ключей SSL и сертификаты издателя в файле со списком доверенных источников. Файл ключей содержит коллекцию сертификатов, каждый из которых может быть представлен во время установки SSL соединения для подтверждения подлинности. В файле со списком доверенных источников хранится коллекция сертификатов, которые считаются достоверными и с которыми будет сравниваться представленный сертификат во время установки SSL-соединения для проверки подлинности.

Хорошим примером реализации протокола SSL является его поддержка в IBM WebSphere Application Server. Система безопасности этого сервера имеет многоуровневую архитектуру, показанную на рисунке 2.

Уровень сетевой безопасности обеспечивает аутентификацию на транспортном уровне, целостность и шифрование сообщений. Коммуникации между различными серверами WebSphere Application Server могут быть сконфигурированы на использование протоколов SSL и HTTPS. Для дополнительной защиты сообщений также можно использовать протоколы IP Security и VPN (Virtual Private Network - виртуальная частная сеть).

Протокол SSL обеспечивает безопасность на транспортном уровне: аутентификацию, целостность и конфиденциальность для безопасного соединения между клиентом и сервером в WebSphere Application Server. Этот протокол работает поверх TCP/IP и под прикладными протоколами, такими как HTTP, LDAP, IIOP, обеспечивая достоверность и секретность передаваемых данных. В зависимости от конфигурации SSL на клиенте и сервере могут быть установлены различные уровни достоверности, целостности данных и секретности. Понимание основ функционирования протокола SSL очень важно для правильной настройки и достижения требуемого уровня защиты для данных клиента и приложения.

Некоторые функции безопасности, предоставляемые протоколом SSL:

• Шифрование данных с целью предотвратить раскрытие конфиденциальных данных во время передачи.
• Подписывание данных с целью предотвратить несанкционированное изменение данных во время передачи.
• Аутентификация клиента и сервера, позволяющая убедиться, что общение ведется с соответствующим человеком или компьютером.

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

Протокол SSL используется различными компонентами внутри WebSphere Application Server для обеспечения достоверности и конфиденциальности. К этим компонентам относятся: встроенный HTTP-транспорт, ORB и безопасный LDAP-клиент.

Реализация SSL, используемая в WebSphere Application Server, - это либо расширение для Java - IBM Java™ Secure Sockets Extension (IBM JSSE), либо IBM System SSL. Провайдер IBM JSSE содержит эталонную реализацию, поддерживающую протоколы SSL и TLS (Transport Layer Security - безопасность транспортного уровня) и API для интеграции. С провайдером IBM JSSE также поставляется стандартный провайдер, предоставляющий поддержку RSA для функциональности цифровой подписи из библиотеки JCA (Java Cryptography Architecture - Архитектура Шифрования для Java) для платформы Java 2, стандартные наборы шифров для SSL и TLS, менеджеров доверенных источников сертификатов и ключей, использующих технологию X509, и реализацию технологии PKCS12 для хранилища цифровых сертификатов JCA.

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

• Провайдер JSSE поддерживает хранение собственного сертификата и сертификатов издателя в файле ключей SSL, но он также поддерживает и отдельный файл, т.н. файл источников сертификатов (trust file). Этот файл может содержать только сертификаты источников. Можно поместить свои собственные сертификаты в файл ключей SSL, а сертификаты издателей - в trust-файл. Это может потребоваться, например, при наличии недорогого аппаратного криптографического устройства, у которого памяти достаточно только для хранения персонального сертификата. В этом случае файл ключей указывает на аппаратное устройство, а trust-файл указывает на файл на диске, содержащий все сертификаты издателей.
• Провайдер JSSE не распознает специальный формат файла ключей SSL, используемый плагином - файлы с расширением.kdb. Провайдер JSSE распознает только стандартные форматы файлов, такие как Java Key Store (JKS - хранилище ключей Java). Совместное использование файлов ключей SSL плагином и сервером приложений невозможно. Более того, для управления ключами сервера приложений и trust-файлами необходимо использовать различные реализации утилиты управления ключами.

SSL и Integrated Solutions Console

Приложение ISC - это единая среда Web-консолей администрирования для развертывания и интеграции консольных модулей, позволяющая заказчикам управлять решениями, а не конкретными продуктами IBM. Эта среда включает в себя контейнер портлетов, Java-компоненты (JMX) для управления приложениями и модули справки Eclipse.

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

Какие преимущества дает использование SSL?

Почему это так важно? Безопасная и эффективная передача данных по открытым коммуникационным каналам - это критический компонент обеспечения функционирования современной ИТ-системы, и протокол SSL позволяет обеспечить эту безопасность. Однако подключение SSL к среде ISC может оказаться сложной и трудоемкой задачей. В чем сложность этой задачи? Вопрос безопасности данных в среде Web-приложений, подобных среде Integrated Solutions Console, может показаться немного размытым для новичков, потому что безопасность ИТ сама по себе - крайне широкая область, охватывающая много различных аспектов в открытых коммуникационных сетях.

В следующих двух статьях этой серии будет представлена организация безопасности данных на основе SSL в среде, основанной на Integrated Solutions Console. Сначала мы рассмотрим настройку и включение SSL для Integrated Solutions Console 5.1 с использованием пустого, собственного и выпущенного издателем сертификатов, а потом разберем, как выполнить те же действия для Integrated Solutions Console 6.0.1.

Перед тем как приступить к разбору темы - маленькое отступление: в январе 2017 года сайт перешел на безопасный протокол https (и вам советует). Также предлагаем и вам помощь в переезде на безопасный протокол . Зачем? Как это сделать? И какой период лучше всего выбрать? Вот об этом сейчас и расскажем.

В статье пойдет речь о переезде сайтов на безопасный протокол HyperText Transfer Protocol Secure (https) . Тема на сегодняшний день считается «заезженной» и рассмотрена на многих ресурсах, но от этого она не становится менее актуальной. Читатели нашего блога и постоянные клиенты часто интересуются - как переехать на https? Зачем мне переходить на https? Нужен ли https для моего сайта? Чтобы ответить на все вопросы разом и помочь тем, кто все еще не разобрался в вопросе, мы и написали эту статью.

Для начала давайте разберемся, что такое https? HyperText Transfer Protocol Secure - это безопасный расширенный протокол http с ключом шифрования для передачи данных или гипертекста (термин «гипертекст» был введен в 1965 американский социологом, философом и первооткрывателем в области информационных технологий Нельсоном, Теодором Холмом), примером гипертекста являются веб-страницы - документы HTML.

HTTPS не является отдельным протоколом. Это обычный HTTP, работающий через шифрованные механизмы SSL и TLS.

Что такое SSL и TLS

SSL - (secure sockets layer - уровень защищённых сокетов) - набор правил с более безопасной связью, регламентирующих применение шифровальных (криптографических) преобразований и алгоритмов в информационных процессах.

TLS - (Transport Layer Security - безопасность транспортного уровня) - протокол, основанный на спецификации протокола SSL версии 3.0. Хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.

С терминологией более менее разобрались, теперь переходим к тому, как заставить наш сайт работать на https.

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

SSL сертификат - уникальная цифровая подпись вашего сайта, основанная на двух типах криптографических ключей - приват и паблик.

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

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

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

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

Более подробную информацию об уже установленном на сайте сертификате вы можете посмотреть с помощью специальных сервисов, таких как:

https://www.ssllabs.com/ssltest/index.html - он передоставит расширенную техническую информацию о сертификате.

https://cryptoreport.websecurity.symantec.com/checker/views/certCheck.jsp - проверит, насколько верно установлен сертификат.

Типы SSL сертификатов по валидации

Что такое SSL сертификат и зачем он нужен вроде разобрались).

Теперь давайте разберем их типы по валидации:

Самоподписанный сертификат. Оговорюсь сразу, данный вид сертификата НЕ подойдет 99% пользователям. Плюс у данного сертификата один - цена (он совершенно бесплатен). Самый весомый минус - при переходе на ваш сайт из поисковой системы или по любому другому заходу пользователю будут показаны вот такие сообщения:

Цена: 0 руб.

Валидация по домену (Domain Validated) - SSL-сертификат, при оформлении которого производится только проверка доменного имени. Также данные сертификаты называют сертификатами начального уровня доверия. Подойдут практически 90% владельцев сайтов. Являются самыми распространенными. Подходят как физическим, так и юридическим лицам. Выдача данного сертификата, как правило, производится в течение суток.

Вид в адресной строке:

Цена: может колебаться от 800 руб./год до 3000 руб./год (хотя эта цифра не предел).

Валидация организации (Organization Validation) - сертификат с повышенной надежностью. При выдаче сертификата производится проверка компании, проверяется не только право владения доменом и принадлежность веб-сайта организации, но и существование компании как таковой. Доступен только юридическим лицам. При выдаче данного сертификата могут быть запрошены следующие документы: свидетельство ИНН/КПП, свидетельство ОГРН, свидетельство о регистрации доменного имени, и.т.д.

Вид в адресной строке:

Цена: может колебаться от 2000 руб./год до 35000 руб./год .

Расширенная валидация (Extended Validation) - сертификат с самым высоким уровнем аутентификации между всеми типами SSL сертификатов. Не подойдет 99% «смертных» из-за своей цены и способа проверки. Предназначен для крупных корпораций. Доступен только юридическим лицам. Зеленая адресная строка браузера отображает название компании и обеспечивает визуальное подтверждение безопасности вашего сайта.

Вид в адресной строке:



Цена: может колебаться от 12000 руб./год до 150000 руб./год .

Еще существует отдельный вид сертификатов, о котором нельзя не сказать - это сертификаты Wildcard . Данный вид сертификата стоит выбрать, если у вас структура сайта представлена в виде поддоменов. Или требуется защита передаваемой информации на субдоменах. На некоторых хостингах данный вид представлен в виде опции.

Цена: может колебаться от 1500 руб./год до 35000 руб./год .

Также для реализации https соединения на некоторых хостингах требуется оплата выделенного IP, цена которого может быть равна
1200 руб./год .

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

Теперь давай разберем, для чего вы прочитали 5716 байт предыдущего текста, и ответим на вопрос - для чего нам нужно переходить на https.

Для чего нужно переходить на https?

Причин несколько и все весомые:

Подходим к завершающей части и ответу на вопрос - как корректно переехать на https с минимальными потерями.

Инструкция по переезду на https

Вот вроде и все. Если сомневаетесь, что справитесь своими силами, обращайтесь к нам . Посмотрим ваш сайт, сориентируем по стоимости и поможем с переездом.

При подготовке материала мы ориентировались на официальные источники Яндекса и Google. Однако, отмечу, что 20 марта 2017 г. в блоге Яндекса была опубликована новая информация по переезду на HTTPS . В связи с этим многим может показаться, будто Яндекс сообщает, о том, что нет необходимости соблюдать пункт №7 данной статьи. В материалах Яндекса это вопрос №4.

Однако обращаем ваше внимание, что в комментариях к этому же материалу Елена Першина (сотрудник компании Яндекс) отвечает Бакалову Игорю: «Редирект лучше настраивать, когда большая часть страниц http-версии будет исключена из поиска», что соответствует рекомендациям из пункту №7 настоящей статьи.

14 июля 2018 22 марта 2019 Просмотров: 14390

В данном материале вы узнаете о том, как установить и настроить SSL-сертификат на Joomla и правильно перевести сайт на HTTPS-протокол. Рассмотрены возможные проблемы и приведены дополнительные действия, которые могут понадобиться при установке, а также после установки SSL на сайт.

Что такое SSL?

SSL (Secure Sockets Layer, пер. уровень защищенных сокетов) - это криптографический протокол, который используется, чтобы обеспечить зашифрованное соединение между сайтом и браузером. SSL сертификат позволяет нам использовать HTTPS.

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

Вы можете сказать: «Мне нечего скрывать, пускай за мной следят». Но давайте рассмотрим подробнее ряд важных преимуществ, которые вы получаете при использовании SSL.

Преимущества использования SSL

1. Защита от перехвата

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

2. Защита клиентов

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

3. Высокие позиции в поисковой выдаче

Сайты, которые загружаются по https при прочих равных условиях получают более высокие позиции от поисковых систем.

4. Интеграции с сервисами

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

5. Визуальные характеристики.

У вашего сайта перед адресом появляется зеленый замочек, или название компании, что для знающих людей, говорит о защите данных, как следствие повышает доверие.

В скором будущем (2 - 3 года) протокол HTTP уйдет в небытие, как небезопасный протокол и будет только защищенное соединение.

Переходим к вопросу, как выбрать SSL-сертификат. С одной стороны, все просто купил сертификат и попросил хостинг-компанию установить сертификат на сайт. Но, есть ряд моментов. И первый - это выбор сертификата.

Виды SSL-сертификатов

SSL сертификаты выпускает ряд компаний (Comodo, Geotrust, Symantec, Thawte) и есть разные уровни сертификатов. Давайте разберемся какой же сертификат нам выбрать.

По уровню доверия сертификаты бывают:

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

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

Количество доменов.

Стандартные SSL сертификаты - выпускаются для защиты одного доменного имени.

Wildcard SSL сертификаты - позволяют активировать защиту для одного домена и множества поддоменов.

Язык.

Стандартные SSL сертификаты - подходят для всех доменов с латинскими буквами. Не подходят для кириллических доменов.

IDN сертификаты - создаются специально для национальных доменов, в нашем случае кириллических.

Брэнд и усиленная защита.

EV (extended validation) сертификаты - сертификаты с расширенной проверкой компании (позвонят по телефону, проверят юридическую информацию). Данный сертификат отличается визуально от всех остальных. В строке браузера перед урл будет зеленая строка с названием вашей компании.

SGC сертификат - это самые мощные сертификаты из доступных на сегодня. Необходим для компаний среднего и крупного бизнеса, а так же если вы хотите хранить данные банковских карт клиентов на своем сайте.

Краткий итог по выбору сертификата.

1. У вас обычный сайт и один домен - берем стандартный сертификат.
2. Если у вас кириллический домен - берем IDN.
3. Хотите защитить несколько поддонов - берем WildCard.
4. Хотите зеленую строку - берем EV.
5. Храните данные банковских карт клиентов на своем сайте - берем SGC.

Приобретение и установка SSL-сертификата

Рассмотрим общие ключевые особенности по приобретению и установке.

Покупка SSL-сертификата

Важные моменты по покупке:

• если вы покупаете стандартный сертификат, то он генерируется автоматически после оплаты и подтверждения вами доменного имени
• доменное имя подтверждается по почте: на E-mail отправляется автоматическое письмо со ссылкой для подтверждения

Для подтверждения требуется электронный адрес вида [email protected] или [email protected]

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

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

После оплаты на E-mail придут данные, которые нужно отправить хостинг-провайдеру, а именно:

• сертификат (начинается со слов begin sertificate ),
• приватный ключ
• цепочки сертификатов, если есть (не обязательно)

Всю установку сертификата к домену проделает хостинг компания.

Выделенный IP-адрес

Устанавливать SSL и переводить сайт на https можно как на прежнем IP-адресе, так и на выделенный (отдельный).

Т.е. можно остаться на прежнем IP-адресе, можно получить новый.

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

Выделенный IP , как правило, платный: стоимость уточняйте у своего хостера.

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

Настройка SSL (https) для Joomla

Что значит нормальная работа по https?

Это когда сайт загружается корректно и у названия сайта горит зеленый значок (во всех браузерах кроме Safari , в этом браузере просто серый замок).

Если же на вашем сайте не все изображения загружаются по протоколу https или найдены другие, вышеперечисленные ошибки, то будет вот такой значок.

Нормальная работа сайта по https предполагает:

1. соответствующий протокол для всех внутренних ссылок сайта
2. https-протокол для CSS- и JS-файлов, картинок и иных подгружаемых файлов
3. отправку данных форм по https
4. редирект страниц с http на https

Поэтому сейчас переходим к настройке Joomla для соблюдения всех необходимых условий.

Изменения в файле конфигурации Joomla

1. открываем файл configuration.php , находим директиву live_site и прописываем https://site.ru (URL без слэша на конце)
2. в этом файле находим опцию force_ssl и ставим значение 2, чтобы админка и внешний интерфейс открывались по протоколу https (если поставим 1, то по защищенному протоколу будет открываться только админка)

Включение SSL в админке Joomla

Опцию force_ssl не обязательно изменять напрямую в файле конфигурации: можно зайти в панель управления Joomla (Система → Общие настройки , вкладка Сервер , раздел Настройки сервера ) и выбрать соответствующее значение для опции Включить SSL :

При этом измениться значение опции force_ssl в файле конфигурации Joomla .

Важно знать:

В настройках некоторых компонентов (VirtueMart, JoomShopping ) также есть опция по включению SSL для редиректа на https страниц данных компонентов.

При правильной настройке сервера и корректной установке SSL-сертификата опция Включить SSL (force_ssl в файле конфигурации) обеспечивает нормальную работу сайта на Joomla по https : все подключаемые файлы и внутренние ссылки будут работать по защищенному протоколу, а при запросе страниц по протоколу http будет происходить редирект на https .

Дополнительные действия для Joomla

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

Изменение в файле.htaccess

В конец файла .htaccess добавляем следующую строку кода:

SetEnvIf X-SSL-Emu on HTTPS=on

Изменение в файле конфигурации

Добавляем в конец файла configuration.php следующую строчку:

$_SERVER["HTTPS"] = "on";

Получится вот так:

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

Редирект главной страницы

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

Код размещаем после строки RewriteEngine On :

RewriteCond %{HTTPS} off
RewriteRule ^(abc/def|ghi)(.*)/?$ https://%{HTTP_HOST}%{REQUEST_URI}

Сейчас ваш сайт всегда будет открываться по протоколу https и будет загружаться со всеми стилями, скриптами и изображениями.

Но! Осталось проделать еще 2 важных пункта.

Пути к изображениям и формам

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

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

Но есть изображения, путь которые вставлены в HTML-код и к ним указан абсолютный путь. Вот у таких изображений нужно в пути вместо http:// написать https:// .

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

На будущее, если вы хотите указать абсолютный путь (полный) к файлу, то прописываем без указания протокола, например //site.ru/images/photo.jpg

Если на вашем сайте есть формы на подписку, то в коде формы меняем URL , на который будут передаваться данные.

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

Как искать изображения, которые загружаются не по https?

Важно знать:

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

Действия после настройки SSL на Joomla

После того, как будет обеспечена нормальная работа страниц сайта по протоколу Https , необходимо осуществить следующие действия:

Сообщить поисковым системам, что сайт переехал на https

Это важный момент в отношении SEO : для поисковых систем сайт, доступный по разным протоколам, будет считаться разными сайтами, что может создать проблемы для продвижения сайта. Чтобы исключить такие проблемы, необходимо воспользоваться соответствующими инструментами поисковых систем:

Заходим в Яндекс.Вебмастер , ставим соответствующую галочку:

Заходим в robots.txt и дописываем директиву host: https://site.ru

В Google Search Console необходимо будет добавить новый сайт с протоколом https , предварительно подтвердив права на него предложенными сервисом способами.

Проверка карты сайта

Обязательно следует проверить карту сайта на то, что все ссылки начинаются c протокола https .

Проверка старых редиректов

Если вы делали редиректы через Redj или RSSEO , то проверьте и подправьте, чтобы конечный адрес был с https .

Другие материалы по безопасности Joomla

Дополнительная защита админки Joomla 3

Восстановление пароля администратора в Joomla 3

SSL-сертификат (https-протокол) Joomla

Akeeba Backup : резервное копирование сайта Joomla

Права на файлы и папки в Joomla 3.x

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

Что такое SSL и что такое TLS?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

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

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

Принцип работы SSL и TLS

Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:

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

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

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

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

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

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

Запрос на подпись (CSR, Certificate Sign Request)

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

Клиентский сертификат

Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

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

$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus ..........+++ ...........................................+++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr 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. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :IT Service Common Name (e.g. server FQDN or YOUR name) :My Company Root Certificate Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name :My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] Getting Private key

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] notAfter=Jan 22 11:49:41 2025 GMT

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

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

$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus ...................................................................................+++ ..........................+++ e is 65537 (0x10001) $ openssl req -new -key server.key -out server.csr 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. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :IT Service Common Name (e.g. server FQDN or YOUR name) :www.mycompany.com Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name : $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] notAfter=Jan 25 12:22:32 2016 GMT

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы.key и.pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

Server { listen 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # Не рекомендуется использовать SSLv3 !!! # Он здесь только для примера ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / { try_files $uri $uri/ =404; } }

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

ServerAdmin [email protected] DocumentRoot /var/www Options FollowSymLinks AllowOverride None Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog ${APACHE_LOG_DIR}/error.log LogLevel warn CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # Эта директива добавляет файл, содержащий список # всех сертификатов, которыми подписан сертификат сервера #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE " \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE " ssl-unclean-shutdown

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

Listen 443

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus ........................+++ ..................................................+++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr 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. ----- Country Name (2 letter code) :RU State or Province Name (full name) :Saint-Petersburg Locality Name (eg, city) :^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr 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. ----- Country Name (2 letter code) :RU State or Province Name (full name) :N/A Locality Name (eg, city) :Saint-Petrersburg Organization Name (eg, company) :My Company Organizational Unit Name (eg, section) :Engineering Common Name (e.g. server FQDN or YOUR name) :Ivan Ivanov Email Address :[email protected] Please enter the following "extra" attributes to be sent with your certificate request A challenge password : An optional company name : $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

Чаще всего, как я уже сказал, используется односторонняя аутентификация, обычно проверяется только сертификат сервера. Давайте посмотрим, как заставить веб-сервер nginx проверять клиентский сертификат. Необходимо в секцию server добавить опции для работы с клиентскими сертификатами:

# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;

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

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

Openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

Curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

Openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

Curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

Curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

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

Запись опубликована автором в рубрике с метками , .

Навигация по записям

: 29 комментариев

1. cl-service.com

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

2. Доброжелатель.

   Тема сисек не раскрыта, ибо описанная технология работы PKI не имеет ничего общего с заголовком темы. Хоть бы для причия ссылки на rfc привел.
   P.S. Был такой анекдот про собаку и блоху.

3. Доброжелатель.

   Нивкоем случае не хотел тебя обидеть. Искал инфу о различии SSl и TLS на практике и твоя ссылка в гугле была первая. Был заинтрегован названием темы. Все круто, так держать!

4. DrAibolit

   Благодарю за толковые пояснения о цифровой сертификации. Я новичок в этом=)
   Надеюсь разъясните следующий вопрос.
   Поскольку в интернет индустрии очень развита тема мошенничества, хотелось бы научиться определять на «вшивость» самостоятельно посещаемые мною сайты (особенно, где присутствуют кашельки и оплаты, инвестиции и т.д) и определять исходя из этого степень моего доверия (приходится часто регистрироваться, оставлять личную информацию, совершать покупки, транзакции, инвестиции). Если я правильно понял, что наличие данной сертификации позволяет сделать такую оценку. Ну и с другой стороны, получить ее не проблема и даже бесплатно.
   Как или с помощью какой программы можно определить наличие цифрового сертификата у того или иного сайта? и желательно его категорию, которая присваивается при выдаче спецорганом SSL DV (выдача сертификата проводится с проверкой только домена), SSL OV (с проверкой организации), EV (с расширенной проверкой юрлица). Мошеннические сайты скорее всего последним вариантом сертификации пользоваться не станут..
   Буду рад, если поведаете еще способы определения надежности сайтов))

   1. mnorin Автор записи

      Какой-то определенной программы для этих целей я еще не встречал, но пару советов по этому поводу могу дать.
      Можно использовать, например, Chromium или Google Chrome. Возьмем, например, сайт https://www.thawte.com/ — компания, которая собственно цифровымисертификатами и занимается.
      В адресной строке будет написано название компании и зеленый замочек. Это значит, что организация проверена, это как минимум SSL OV.
      Если кликнуть на замочек, а в выпавшем окошке «Details», а затем «View Certificate», то можно увидеть информацию о сертификате. Для Thawte сертификат подписан следующим сертификатом: «thawte Extended Validation SHA256 SSL CA», а сертификат для click.alfabank.ru тоже подписан Thawte, но другим сертификатом. Это «thawte EV SSL CA — G3», то есть они тоже проходили Extended Validation.
      Как-то так.

5. Руслан

   Раздел «Принцип работы SSL и TLS», «Клиент генерирует случайную цифровую последовательность».

   Я был уверен что клиент генерирует сеансовый закрытый и, соответственно, открытый ключи (который вы, очевидно, и назвали «цифровая последовательность»). Открытый ключ передаётся серверу и сервер шифрует пакеты в сторону клиента сеансовым открытым клиентским ключом.

   Уточните, пожалуйста.

6. Новичок

   Статья очень полезная! Даже есть практические примеры=) Только я не понял одну вещь — в чем различие между корневым сертификатом и серверным? или это одно и тоже?

7. Виталий

   Здравствуйте.
   Хостер предложил услугу - SSL для виртуальных серверов. Воспользовались. Оказалось, что для третьего уровня, т.е. http://www.site.ru сертификат недействителен, только для site.ru. Притом, посетителей упорно кидает на протокол https, не важно, заходят они на site.ru или на http://www.site.ru . Разумеется, во втором случае браузер начинает истошно ругаться, а посетитель до сайта так и не добирается.
   А для тех, кто до сайта таки добрался, сайт стал выглядеть криво, пропала часть меню, перестала отображаться часть картинок в выдаче некоторыми компонентами.