Как браузер проверяет ssl сертификат
У сайта domain.com есть Thawte SSL сертификат.
Обычная схема — у клиента сертификата нет, он просто заходит на сайт и если сертификат поддельный видит что этому сайту нельзя доверять.
Браузер клиента запрашивает IP домена domain.com у DNS, устанавливает соединение с этим IP и получает открытый ключ и сертификат, а далее браузер проверяет подлинность сертификата. объясните пожалуйста как?
| Оглавление |
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 13:45 , 14-Ноя-11, ( 1 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Radiante, 13:50 , 14-Ноя-11, ( 2 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 14:42 , 14-Ноя-11, ( 3 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Radiante, 14:57 , 14-Ноя-11, ( 4 )
- Объясните плиз как браузер проверяет SSL сертификат ?, reader, 15:53 , 14-Ноя-11, ( 5 )
- Объясните плиз как браузер проверяет SSL сертификат ?, PavelR, 15:56 , 14-Ноя-11, ( 7 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 16:08 , 14-Ноя-11, ( 8 )
- Объясните плиз как браузер проверяет SSL сертификат ?, PavelR, 16:36 , 14-Ноя-11, ( 10 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 17:00 , 14-Ноя-11, ( 11 )
- Объясните плиз как браузер проверяет SSL сертификат ?, жора, 19:42 , 14-Ноя-11, ( 12 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 22:35 , 14-Ноя-11, ( 14 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Aleks305, 22:47 , 14-Ноя-11, ( 15 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 08:20 , 15-Ноя-11, ( 16 )
Сообщения по теме [Сортировка по времени | RSS] > Браузер клиента запрашивает IP домена domain.com у DNS, устанавливает соединение с этим
> IP и получает открытый ключ и сертификат, а далее браузер проверяет
> подлинность сертификата. объясните пожалуйста как?https://developer.mozilla.org/en/Introduction_to_SSL Читаем и объясняем для себя — как и что.
>> Браузер клиента запрашивает IP домена domain.com у DNS, устанавливает соединение с этим
>> IP и получает открытый ключ и сертификат, а далее браузер проверяет
>> подлинность сертификата. объясните пожалуйста как?
> https://developer.mozilla.org/en/Introduction_to_SSL Читаем и объясняем для себя —
> как и что.спасибо. а можно в двух словах суть? верно ли что сертификаты от центров нужны только чтобы удостовериться что DNS выдал верный IP и мы попали на реальный сайт, а не фишинговый?
> спасибо. а можно в двух словах суть? верно ли что сертификаты от
> центров нужны только чтобы удостовериться что DNS выдал верный IP и
> мы попали на реальный сайт, а не фишинговый?Cертификат выдает не Центр. Сертификат выдает сервер (который ДО этого получил сертификат у CA — за определенные деньги), клиент же, получив сертификат, шлет запрос одному из CA (который указана в сертификате) на получение подтверждения, что сервер, который выдал сертификат является именно тем, за кого себя выдает. Собственно, на этом построен бизнес этих самых CA. На одном из таких (Thawte) небезызвестный Шаттлворт сделал очень большие деньги. Потом он продал бизнес не менее известной VeriSign. Простите за оффтоп.
Думаю, так. 🙂 Или надо еще подробнее? Более подробнее — не интересовался. На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на самом сервере и не подписанные CA. Доверять им или нет — личное дело пользователя.>[оверквотинг удален]
> сертификат у CA — за определенные деньги), клиент же, получив сертификат,
> шлет запрос одному из CA (который указана в сертификате) на получение
> подтверждения, что сервер, который выдал сертификат является именно тем, за кого
> себя выдает. Собственно, на этом построен бизнес этих самых CA. На
> одном из таких (Thawte) небезызвестный Шаттлворт сделал очень большие деньги. Потом
> он продал бизнес не менее известной VeriSign. Простите за оффтоп.
> Думаю, так. 🙂 Или надо еще подробнее? Более подробнее — не интересовался.
> На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на
> самом сервере и не подписанные CA. Доверять им или нет —
> личное дело пользователя.это я все знаю, это и так понятно. вопрос как технически это происходит? в чем защита? ведь клиент не получает закрытого ключа, он получает данные доступные любому, кто зашел на сайт, и если сайт поддельный то он даст те же данные сертификата, и браузер запросив подтверждение у CA так же получит положительный ответ.
В же чем защита?>[оверквотинг удален]
>> Думаю, так. 🙂 Или надо еще подробнее? Более подробнее — не интересовался.
>> На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на
>> самом сервере и не подписанные CA. Доверять им или нет —
>> личное дело пользователя.
> это я все знаю, это и так понятно. вопрос как технически это
> происходит? в чем защита? ведь клиент не получает закрытого ключа, он
> получает данные доступные любому, кто зашел на сайт, и если сайт
> поддельный то он даст те же данные сертификата, и браузер запросив
> подтверждение у CA так же получит положительный ответ.
> В же чем защита?в сертификате указан публичный ключ который и будет использовать клиент и что бы им что-то правильно расшифровать, нужно что бы сервер шифровал правильным закрытым ключом
>[оверквотинг удален]
>>> личное дело пользователя.
>> это я все знаю, это и так понятно. вопрос как технически это
>> происходит? в чем защита? ведь клиент не получает закрытого ключа, он
>> получает данные доступные любому, кто зашел на сайт, и если сайт
>> поддельный то он даст те же данные сертификата, и браузер запросив
>> подтверждение у CA так же получит положительный ответ.
>> В же чем защита?
> в сертификате указан публичный ключ который и будет использовать клиент и что
> бы им что-то правильно расшифровать, нужно что бы сервер шифровал правильным
> закрытым ключом. т.е. поддельному сайту нужно иметь приватный(закрытый) ключ, соответствующий сертификату. А закрытый ключ, как уже было выше замечено, «клиент не получает», т.е. по сети не передается.
> это я все знаю, это и так понятно. вопрос как технически это
> происходит? в чем защита? ведь клиент не получает закрытого ключа, он
> получает данные доступные любому, кто зашел на сайт, и если сайт
> поддельный то он даст те же данные сертификата, и браузер запросив
> подтверждение у CA так же получит положительный ответ.
> В же чем защита?Уже всё разъяснили, попробую ещё проще.
Сервер присылает свой сертификат, в котором помимо своего открытого ключа есть цифровая подпсь CA, где закрытым ключем CA зашифровано: «Верь, Вася. Это в самом деле ключ сайта pupkin.ru»
Клиент в своей базе находит открытый ключ CA и расшифровывает эту сигнатуру.>> спасибо. а можно в двух словах суть? верно ли что сертификаты от
>> центров нужны только чтобы удостовериться что DNS выдал верный IP и
>> мы попали на реальный сайт, а не фишинговый?
> Cертификат выдает не Центр. Сертификат выдает сервер (который ДО этого получил
> сертификат у CA — за определенные деньги), клиент же, получив сертификат,
> шлет запрос одному из CA (который указана в сертификате) на получение
> подтверждения, что сервер, который выдал сертификат является именно тем, за кого
> себя выдает.ну и зачем вводить в заблуждение?
Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет валидность сертификата. Валидность — это степень доверия, определяется, действительно ли подписан ли полученный сертификат корневым или нет. Если подписан, то тогда «типа да, доверяем».
Кроме этой проверки, есть еще проверка на отозванность сертификата, которая да, осуществляется путем отправки запроса на получение списка CRL — certificate revocation list-а, т.е. списка отзыва сертификатов. При этом полученный сертификат не должен быть отозван, отозван — значит не действителен, не доверяем.
> Собственно, на этом построен бизнес этих самых CA.
Кроме денег за выдачу, ЦА может брать деньги за отзыв сертификата (за размещение в CRL) =)
> На одном из таких (Thawte) небезызвестный Шаттлворт сделал очень большие деньги. Потом
> он продал бизнес не менее известной VeriSign. Простите за оффтоп.
> Думаю, так. 🙂 Или надо еще подробнее? Более подробнее — не интересовался.
> На всякий случай замечу, что есть еще самоподписанные сертификаты. Сгенерированные на
> самом сервере и не подписанные CA. Доверять им или нет —
> личное дело пользователя.> ну и зачем вводить в заблуждение?
> Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет
> валидность сертификата. Валидность — это степень доверия, определяется, действительно
> ли подписан ли полученный сертификат корневым или нет. Если подписан, то
> тогда «типа да, доверяем».Я правильно понял Вашу мысль? То есть — клиент ВООБЩЕ не обращается к CA, у которого запрашивает достоверность полученного сертификата? А сравнивает с некой своей базой сертфикатов, хранящихся у самого клиента (в браузере)? По-моему, Вы не правы. Но спорить не буду — просто не интересовался подробностями.
>> ну и зачем вводить в заблуждение?
>> Клиент, получив сертификат, используя имеющуюся у себя базу корневых сертификатов, проверяет
>> валидность сертификата. Валидность — это степень доверия, определяется, действительно
>> ли подписан ли полученный сертификат корневым или нет. Если подписан, то
>> тогда «типа да, доверяем».
> Я правильно понял Вашу мысль? То есть — клиент ВООБЩЕ не
> обращается к CA, у которого запрашивает достоверность полученного сертификата? А сравнивает
> с некой своей базой сертфикатов, хранящихся у самого клиента (в браузере)?
> По-моему, Вы не правы.сначала проверяет по внутренней базе.
а иначе откуда он будет знать, как обратиться к СА ?> Но спорить не буду — просто не интересовался подробностями.
обращается за проверкой по CRL.
> сначала проверяет по внутренней базе.
> а иначе откуда он будет знать, как обратиться к СА ?Список CA есть в каждом браузере — называются CTL — Certificate Trust Lists. Оттуда и знает. Кроме того — имя CA есть в самом сертификате, который посылает сервер на этапе хэндшейкинга (первичной фазы SSL-сеанса).
> обращается за проверкой по CRL.
CRL — проверка не действенность (неотозванность) сертификата — всего лишь одна из фаз проверки. В описании выше я о ней не указал — согласен. 🙂 Просто забыл.
Дядь Федор.
Открытые ключи CA общеизвестны и хранятся локально в браузере и/или ОС, поэтому для проверки подписи CA обращаться к нему лично нет необходимости и браузеры обычно этого не делают. Тобиш, SSL будет работать, даже если сам CA недоступен.Остается упомянутый выше механизм CRL. 😉 Вот тут уж никуда без запроса.
> Остается упомянутый выше механизм CRL. 😉 Вот тут уж никуда без запроса.
Вот уж я сомневаюсь, что CRL засасывается Вашим компом у CA всякий раз, когда Вы открываете https-ный сайт. Читайте, как обновляется CRL в Windows.
Как работает SSL-сертификат?
SSL защищает пароли, номера и CVV-коды кредитных карт от перехвата мошенниками. Данные нельзя украсть благодаря безопасному HTTPS-соединению. От обычного HTTP оно отличается двухэтапным шифрованием трафика по протоколу TLS:
- Асимметричное шифрование. Браузер пользователя и сервер идентифицируют друг друга с помощью закрытого–открытого ключей и устанавливают защищенное соединение.
- Симметричное шифрование. Браузер пользователя и сервер договариваются о симметричном ключе, чтобы передавать данные быстро и с меньшими затратами вычислительных мощностей.
Зашифрованное HTTPS-соединение безопасно по двум причинам:
Аутентификация сервера
Для доступа к конфиденциальным данным мошенники создают фальшивые сайты и привлекают посетителей из рассылки и чатов. Например, на почту приходит письмо: «Ваш аккаунт на сайте site.ru взломан! Срочно перейдите по ссылке и смените пароль!». Это называется фишинг. Внешне такие страницы очень похожи на настоящие – пользователи доверяют бренду, вводят пароли и теряют деньги.
Чтобы отличить реальный сайт, нужно проверить подлинность SSL-сертификата. Вот как это происходит:
- при подключении к ресурсу ваш браузер связывается с центром выдачи сертификата и сверяет его цифровую подпись;
- если она не подделана и не просрочена – сайт обозначается как надёжный.
Переходим к следующему этапу аутентификации:
- браузер шифрует сообщение с помощью публичного ключа сертификата и передаёт на сервер;
- сервер расшифровывает сообщение приватным ключом, который есть только у него.
Сайт опознается как подлинный. Вы уверены, что соединяетесь с реальным магазином/банком/платежным сервисом, а не фишинговым.
Защищенный канал
Мошенник может не создавать поддельный сайт, а просто перехватить информацию.
При HTTP-соединении данные передаются в открытом виде – их легко украсть и использовать. При HTTPS-соединении информация шифруется – ее можно перехватить, но не получится использовать. Для этого понадобится секретный ключ, а он есть только у владельца сайта.
Благодаря аутентификации сервера и шифрованию трафика технология SSL защищает данные пользователей и репутацию сайтов. Если на сайте установлен сертификат, мошенники не могут подделать ресурс или расшифровать украденную информацию.
Другие вопросы из категории
Как работает SSL-сертификат
Рассказываем, как браузер и сайт устанавливают безопасное соединение
Зачем нужен SSL-сертификат
В браузере перед адресами одних сайтов отображаются буквы HTTP, а перед другими — HTTPS. Обе аббревиатуры обозначают одно и то же: протокол передачи данных в интернете. Протокол — это набор правил, который определяет, как браузер и сервер обмениваются данными, какие бывают данные и что с ними делать.
HTTP — обычный протокол, он работает по умолчанию. Вы вводите на сайте личную информацию, а браузер передаёт её на сервер в открытом виде.
HTTPS — защищённая версия HTTP. Это SSL-протокол, который активируется после установки SSL-сертификата и зашифровывает личную информацию, перед тем как передать её владельцу сайта.
Представьте, что планируете отпуск и покупаете билеты на самолёт на сайте авиакомпании. Чтобы оплатить заказ, вы вводите детали банковской карты. Этого не видно, но браузер передаёт эти детали серверу. Если сообщение перехватят злоумышленники, они узнают детали карты и смогут расплачиваться ею в интернете.
Чтобы этого не произошло, проверяйте, есть ли на сайте SSL-сертификат. Даже если мошенники перехватят ваши данные на сайте с сертификатом, они увидят только случайный набор символов.
Разберемся, как работает SSL-сертификат, и рассмотрим принцип работы HTTPS-соединения.
Хотите сделать свой сайт безопасным?
Принцип работы SSL-шифрования
В основе любого метода шифрования лежит ключ. Ключ — это способ зашифровать или расшифровать сообщение. В работе SSL-сертификата участвуют три ключа: публичный, приватный и сеансовый.
Публичный ключ зашифровывает сообщение. Браузер использует его, когда нужно отправить пользовательские данные серверу. Например, после того как вы ввели данные банковской карты и нажали «Оплатить». Этот ключ виден всем, браузер прикрепляет его к сообщению.
Приватный ключ расшифровывает сообщение. Его использует сервер, когда получает сообщение от браузера. Этот ключ хранится на сервере и никогда не передаётся вместе с сообщением.
Сеансовый ключ одновременно зашифровывает и расшифровывает сообщения. Браузер генерирует его на время, которое пользователь проводит на сайте. Стоит пользователю закрыть вкладку, сеанс закончится и ключ перестанет работать.
Публичный и приватный ключи генерируются один раз при создании запроса на выпуск сертификата. Поэтому приватный ключ нужно хранить осторожно. Если ключ попадёт в руки другому человеку, он сможет расшифровывать сообщения, а вам придётся переустанавливать сертификат.
Шифрование с двумя разными ключами называют асимметричным. Использовать такой метод более безопасно, но медленно. Поэтому браузер и сервер используют его один раз: чтобы создать сеансовый ключ.
Шифрование с одним ключом называют симметричным. Этот метод удобен, но не так безопасен. Поэтому браузер и делает уникальный ключ для каждого сеанса вместо того, чтобы хранить его на сервере.
Как браузер и сервер устанавливают безопасное соединение
Браузер и сервер устанавливают SSL-соединение каждый раз, когда пользователь заходит на сайт. Это занимает несколько секунд во время загрузки сайта. По-английски процесс называется handshake. Это означает «рукопожатие».
Когда вы вводите адрес сайта в браузере, он спрашивает у сервера, установлен ли для сайта сертификат. В ответ сервер отправляет общую информацию об SSL-сертификате и публичный ключ. Браузер сверяет информацию со списком авторизованных центров сертификации. Такой список есть во всех популярных браузерах. Если всё в порядке, браузер генерирует сеансовый ключ, зашифровывает его публичным ключом и отправляет на сервер. Сервер расшифровывает сообщение и сохраняет сеансовый ключ. После этого между браузером и сайтом устанавливается безопасное соединение через протокол HTTPS.
Процесс можно сравнить со звонком в домофон. Когда вы слышите звонок, спрашиваете кто пришел. Скорее всего, вы не откроете дверь, пока не убедитесь, что это ваш знакомый. У SSL-сертификата похожий принцип работы: браузер не настроит безопасное соединение с сайтом, пока не убедится, что сертификат не поддельный.
Рассмотрим, как работает HTTPS-соединение на схеме:
- 1 Вы вводите в браузере доменное имя.
- 2 Сервер отправляет информацию об SSL-сертификате и публичный ключ.
- 3 Браузер проверяет информацию, генерирует сеансовый ключ, зашифровывает его публичным ключом и отправляет назад.
- 4 Сервер расшифровывает сеансовый ключ.
- 5 Безопасное соединение установлено.
«Как это работает»: знакомство с SSL/TLS
Мы достаточно часто рассказываем о разных технологиях: от систем хранения до резервного копирования. Помимо этого мы делимся собственным опытом оптимизации работы нашего IaaS-провайдера — говорим об управленческих аспектах и возможностях для улучшения usability сервиса.
Сегодня мы решили затронуть тему безопасности и поговорить об SSL. Всем известно, что сертификаты обеспечивают надежное соединение, а мы разберёмся в том, как именно это происходит, и взглянем на используемые протоколы.
/ Flickr / David Goehring / CC-BY
SSL (secure sockets layer — уровень защищённых cокетов) представляет собой криптографический протокол для безопасной связи. С версии 3.0 SSL заменили на TLS (transport layer security — безопасность транспортного уровня), но название предыдущей версии прижилось, поэтому сегодня под SSL чаще всего подразумевают TLS.
Цель протокола — обеспечить защищенную передачу данных. При этом для аутентификации используются асимметричные алгоритмы шифрования (пара открытый — закрытый ключ), а для сохранения конфиденциальности — симметричные (секретный ключ). Первый тип шифрования более ресурсоемкий, поэтому его комбинация с симметричным алгоритмом помогает сохранить высокую скорость обработки данных.
Рукопожатие
Когда пользователь заходит на веб-сайт, браузер запрашивает информацию о сертификате у сервера, который высылает копию SSL-сертификата с открытым ключом. Далее, браузер проверяет сертификат, название которого должно совпадать с именем веб-сайта.
Кроме того, проверяется дата действия сертификата и наличие корневого сертификата, выданного надежным центром сертификации. Если браузер доверяет сертификату, то он генерирует предварительный секрет (pre-master secret) сессии на основе открытого ключа, используя максимально высокий уровень шифрования, который поддерживают обе стороны.
Сервер расшифровывает предварительный секрет с помощью своего закрытого ключа, соглашается продолжить коммуникацию и создать общий секрет (master secret), используя определенный вид шифрования. Теперь обе стороны используют симметричный ключ, который действителен только для данной сессии. После ее завершения ключ уничтожается, а при следующем посещении сайта процесс рукопожатия запускается сначала.
Алгоритмы шифрования
Для симметричного шифрования использовались разные алгоритмы. Первым был блочный шифр DES, разработанный компанией IBM. В США его утвердили в качестве стандарта в 70-х годах. В основе алгоритма лежит сеть Фейстеля с 16-ю циклами. Длина ключа составляет 56 бит, а блока данных — 64.
Развитием DES является алгоритм 3DES. Он создавался с целью совершенствования короткого ключа в алгоритме-прародителе. Размер ключа и количество циклов шифрования увеличилось в три раза, что снизило скорость работы, но повысило надежность.
Еще был блочный шифр RC2 с переменной длиной ключа, который работал быстрее DES, а его 128-битный ключ был сопоставим с 3DES по надежности. Потоковый шифр RC4 был намного быстрее блочных и строился на основе генератора псевдослучайных битов. Но сегодня все эти алгоритмы считаются небезопасными или устаревшими.
Самым современным признан стандарт AES, который официально заменил DES в 2002 году. Он основан на блочном алгоритме Rijndael и скорость его работы в 6 раз выше по сравнению с 3DES. Размер блока здесь равен 128 битам, а размер ключа — 128/192/256 битам, а количество раундов шифрования зависит от размера ключа и может составлять 10/12/14 соответственно.
Что касается асимметричного шифрования, то оно чаще всего строится на базе таких алгоритмов, как RSA, DSA или ECC. RSA (назван в честь авторов Rivest, Shamir и Adleman) используется и для шифрования, и для цифровой подписи. Алгоритм основан на сложности факторизации больших чисел и поддерживает все типы SSL-сертификатов.
DSA (Digital Signature Algorithm) используется только для создания цифровой подписи и основан на вычислительной сложности взятия логарифмов в конечных полях. По безопасности и производительности полностью сопоставим с RSA.
ECC (Elliptic Curve Cryptography) определяет пару ключей с помощью точек на кривой и используется только для цифровой подписи. Основным преимуществом алгоритма является более высокий уровень надежности при меньшей длине ключа (256-битный ECC-ключ сопоставим по надежности с 3072-битным RSA-ключом.
Более короткий ключ также влияет на время обработки данных, которое заметно сокращается. Этот факт и то, что алгоритм эффективно обрабатывает большое количество подключений, сделали его удобным инструментом для работы с мобильной связью. В SSL-сертификатах можно использовать сразу несколько методов шифрования для большей защиты.
Хеш и MAC
Цель хеш-алгоритма — преобразовывать все содержимое SSL-сертификата в битовую строку фиксированной длины. Для шифрования значения хеша применяется закрытый ключ центра сертификации, который включается в сертификат как подпись.
Хеш-алгоритм также использует величину, необходимую для проверки целостности передаваемых данных — MAC (message authentication code). MAC использует функцию отображения, чтобы представлять данные сообщения как фиксированное значение длины, а затем хеширует сообщение.
В протоколе TLS применяется HMAC (hashed message authentication code), который использует хеш-алгоритм сразу с общим секретным ключом. Здесь ключ прикрепляется к данным, и для подтверждения их подлинности обе стороны должны использовать одинаковые секретные ключи, что обеспечивает большую безопасность.
Все алгоритмы шифрования сегодня поддерживают алгоритм хеширования SHA2, чаще всего именно SHA-256. SHA-512 имеет похожую структуру, но в нем длина слова равна 64 бита (вместо 32), количество раундов в цикле равно 80 (вместо 64), а сообщение разбивается на блоки по 1024 бита (вместо 512 бит). Раньше для тех же целей применялся алгоритм SHA1 и MD5, но сегодня они считаются уязвимыми.
Разговоры об отказе от SHA1 велись достаточно давно, но в конце февраля алгоритм был официально взломан. Исследователям удалось добиться коллизии хешей, то есть одинакового хеша для двух разных файлов, что доказало небезопасность использования алгоритма для цифровых подписей. Первая попытка была сделана еще в 2015, хотя тогда удалось подобрать только те сообщения, хеш которых совпадал. Сегодня же речь идет о целых документах.
Сертификаты бывают разные
Теперь, когда мы разобрались, что представляет собой протокол SSL/TLS и как происходит соединений на его основе, можно поговорить и о видах сертификатов.
Domain Validation, или сертификаты с проверкой домена, подходят для некоммерческих сайтов, так как они подтверждают только веб-сервер, обслуживающий определенный сайт, на который был осуществлен переход. Этот вид сертификата самый дешевый и популярный, но не может считаться полностью безопасным, так как содержит только информацию о зарегистрированном доменном имени.
Organization Validation, или сертификаты с проверкой организации, являются более надежными, так как подтверждают еще регистрационные данные компании-владельца. Эту информацию юридическое лицо обязано предоставить при покупке сертификата, а удостоверяющий центр может связаться напрямую с компанией для подтверждения этой информации. Сертификат отвечает стандартам RFC и содержит информацию о том, кто его подтвердил, но данные о владельце не отображаются.
Extended Validation, или сертификат с расширенной проверкой, считается самым надежным. Собственно, зеленый замочек или ярлык в браузере означает как раз то, что у сайта есть именно такой сертификат. О том, как разные браузеры информируют пользователей о наличии сертификата или возникающих ошибках можно почитать тут.
Он нужен веб-сайтам, которые проводят финансовые транзакции и требуют высокий уровень конфиденциальности. Однако многие сайты предпочитают перенаправлять пользователей для совершения платежей на внешние ресурсы, подтвержденные сертификатами с расширенной проверкой, при этом используя сертификаты OV, которых вполне хватает для защиты остальных данных пользователей.
Кроме того, сертификаты могут различаться в зависимости от количества доменов, на которые они были выданы. Однодоменные сертификаты (Single Certificate) привязываются к одному домену, который указывается при покупке. Мультидоменные сертификаты (типа Subject Alternative Name, Unified Communications Certificate, Multi Domain Certificate) будут действовать уже для большего числа доменных имен и серверов, которые также определяются при заказе. Однако за включение дополнительных доменов, свыше определенной нормы, потребуется платить отдельно.
Еще существуют поддоменные сертификаты (типа WildCard), которые охватывают все поддомены указанного при регистрации доменного имени. Иногда могут потребоваться сертификаты, которые будут одновременно включать не только несколько доменов, но и поддомены. В таких случаях можно приобрести сертификаты типа Comodo PositiveSSL Multi-Domain Wildcard и Comodo Multi-Domain Wildcard SSL или (лайфхак) обычный мультидоменный сертификат, где в списке доменов указать также и нужные поддоменные имена.
Получить SSL-сертификат можно и самостоятельно: пара ключей для этого генерируется через любой генератор, например, бесплатный OpenSSL. И такой защищенный канал связи вполне получится использовать для внутренних целей: между устройствами своей сети или приложениями. Но вот для использования на веб-сайте сертификат необходимо приобретать официально, чтобы в цепочке подтверждения сертификатов обязательно имелся корневой сертификат, браузеры не показывали сообщений о небезопасном соединении, а пользователи были спокойны за свои данные.
P.S. Дополнительно по теме из блога IaaS-провайдера 1cloud:
- Кириллические домены и SSL-сертификаты
- Цепочки SSL-сертификатов
- Зачем покупать SSL-сертификат
- Как узнать, из чего состоит SSL-сертификат
- SSL SSL-ю рознь: какой сертификат выбрать
- Объясните плиз как браузер проверяет SSL сертификат ?, Aleks305, 22:47 , 14-Ноя-11, ( 15 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 22:35 , 14-Ноя-11, ( 14 )
- Объясните плиз как браузер проверяет SSL сертификат ?, жора, 19:42 , 14-Ноя-11, ( 12 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 17:00 , 14-Ноя-11, ( 11 )
- Объясните плиз как браузер проверяет SSL сертификат ?, PavelR, 16:36 , 14-Ноя-11, ( 10 )
- Объясните плиз как браузер проверяет SSL сертификат ?, reader, 15:53 , 14-Ноя-11, ( 5 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Radiante, 14:57 , 14-Ноя-11, ( 4 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Дядя_Федор, 14:42 , 14-Ноя-11, ( 3 )
- Объясните плиз как браузер проверяет SSL сертификат ?, Radiante, 13:50 , 14-Ноя-11, ( 2 )