Зачем нужен корневой сертификат?
Вторая попытка 😉
Собственно, я понимаю, что корневой сертификат подписывает все остальные и позволяет убедиться, что сертификат сайта настоящий.
Но.
Сайты обычно уже отдают всю цепочку сертификатов, включая корневой.
Зачем же его обычно добавляют в систему? Оо
Его ж сайт отдаёт!
Или корневой сертификат на сайте и в системе — это две разные сущности?
- Вопрос задан более года назад
- 99 просмотров
Комментировать
Решения вопроса 1
Михаил @Akela_wolf
Extreme Programmer
Ну вот представьте: мошенник Вася выпустил корневой самоподписанный сертификат. А затем подписал им цепочку до фишингового сайта mmoney.com
Пользователь Петя зашел на сайт, получил всю цепочку сертификатов, включая корневой сертификат; цепочка, разумеется, валидна. И ввел данные своей кредитки, будучи уверен что имеет дело с нормальным сайтом.
Вот чтобы такого не происходило, не только цепочка сертификатов должна быть валидна, но и корневой сертификат (с которого собственно начинается цепочка) должен быть признан надежным. Именно для этого надежные сертификаты добавляют в операционную систему (и пользователь может сам добавить новый корневой сертификат, если считает его заслуживающим доверия)
Ответ написан более года назад
Нравится 1 3 комментария
Вова @JustMoose Автор вопроса
То есть, сертификат один, но в двух местах (система и сайт). И вся проверка сводится к тому, чтобы убедиться, что они совпали?
Вова, система доверяет только своему. Серверу вообще не рекомендуется слать корневой в ответе
Вова @JustMoose Автор вопроса
galaxy, понял, спасибо!
Ответы на вопрос 2
Это вопрос доверия. Сертификаты могут быть подписаны другими сертификатами, это гарантирует целостность цепочки, но в итоге все это должно быть заверено стороной, которой вы (браузер) безусловно доверяет.
Если сайт вам сам присылает корневой сертификат, как вы можете ему доверять?
Распространение таких корневых точек доверия — важная часть построения всей системы PKI (Public key infrastructure), и это не криптографическая проблема, а социально-техническая.
Ответ написан более года назад
Вова @JustMoose Автор вопроса
Про систему доверия то понятно. Я просто задумался, как оно работает, кхм, в коде 😉
CityCat4 @CityCat4 Куратор тега Цифровые сертификаты
Внимание! Изменился адрес почты!
Я не так давно отвечал на этот вопрос.
Если что-то непонятно — спрашивайте, зачем задавать один и тот же вопрос повторно?
Ответ написан более года назад
Вова @JustMoose Автор вопроса
Сорри.
Просто я посчитал два этих вопроса ортогональными.
Один про то, как работает цепочка сертификатов.
Второй, как оно проверяется «внутри».
CityCat4 @CityCat4 Куратор тега Цифровые сертификаты
Вова, там нет никакого «внутри». Если корневой сертификат в том хранилище, которое у тебя в системе считается хранилищем доверенных корневых — все, ему полное доверие и всем сертификатам, выпущенным им — полное доверие. Цепочку сертификатов кстати, сайт может и не передавать — только свой сертификат, и может оказаться твоей проблемой подкачать нужный корневой.
Вся эта гигантская пирамида (по на##алову) держится (ну то есть держалась) на доверии.
Зачем нужны корневые сертификаты?
Немного запутался в причинно-следственных связях.
Разбираюсь с SSL сертификатами. Вроде понял, что специальный центр выпускает сертификаты, при этом он, по сути, подписывает СВОИМ сертификатом свежесоздаваемые.
После этого сертификат (свежесозданный) устанавливается на сайт и позволяет гарантировать, что сайт «настоящий».
Кажется, что вся эта конструкция держится на том, что тот единственный корневой (?) сертификат, которым подписаны все остальные, есть только у удостоверяющего центра.
Теперь вопрос: почему все так боятся, что кто-то установит в их систему левый корневой сертификат? И сразу второй вопрос: почему какой-нибудь Fiddler, который устанавливает в систему свой корневой сертификат вообще работает?
Ведь при заходе на какой-нибудь сайт у него будет свой собственный серт, подписанный вполне себе конкретным корневым сертификатом. А не тем левым, который кто-то подложил в систему.
Почему же «левые» корневые сертификаты вообще работают, если никто и ничего ими ещё не подписал?
- Вопрос задан более года назад
- 4049 просмотров
Комментировать
Решения вопроса 1
На примере наших госсайтов
Есть сайт на котором должно работать шифрование ssl. Но наши не хотят делать нормально, потому что крогом враги, и делают СВОЙ ssl серт, подписывая его СВОИМ центром сертиф.
В итоге при переходе на сайт — браузер будет ругаться, т.к. ssl он видит, но проверить кем выпущен не может, т.к. не публичный центр сертиф его выпустил
Для того чтобы этого не происходило — в систему требуют поставить корневой серт от нашего центра сертификации. После этого браузер перестанет ругаться, т.к. теперь он может отследить этот сертификат сайта(и проверить) до центра сертификации
Почему нельзя устанавливать левые сертификаты от центров(в том числе российские и вообще любые, мое мнение)
Потому что переходя на сайт того же гугл, сертификат сайта проверяется центром от гугла, и если этот сайт подменит провайдер — Вы об этом узнаете в браузере
Но, если Вы установили левый серти от центра, и он выпустит серт для сайта гугл, а провайдер подменит эту страницу на свою — браузер не будет ругаться, т.к. у него совпадет ssl сертификат сайта с тем, что указано в корневом(от центра серт).
По такому же принципу делают прокси-серверы во многих компания, ставя свой серт на ПК юзверей. Это позволяет им расшифровать весь трафф, который идет в шифрованном виде. И как следствия — получить и записать информацию — че там на сайте делал пользователь( от чего по идее и защищает ssl , от подмены сайта и перехвата вводимой на нём информации)
Ответ написан более года назад
Вова @JustMoose Автор вопроса
Ага! Значит надо не только корневой сертификат установить, но ещё и обычный подменить. Да, так понятней.
Спасибо!
ЗЫ: Ну, не то чтобы «наши не хотят сделать нормально». Насколько я понял центры а-ля GlobalSign взяли и отозвали часть сертификатов под соусом санкций.
Вова, ну наши госструктуры задолго до этого свои серт делали. так что это не связано
Вова, только глобалсигн так м сделал. За что его справедливо осудили.
Ну и гостовские сертификаты и до этого были, как выше и ответили
Вова @JustMoose Автор вопроса
Василий Банников, А что не так с ГОСТовыми сертификатами?
Вова, в том что это потенциальный mitm от ФСБ, тк корневой сертификат у госкомпании
Вова @JustMoose Автор вопроса
Василий Банников, не очень понял, как связаны между собой ГОСТ и MITM. Вроде бы для осуществления MITM достаточно поставить в систему любой подходящий корневой сертификат, не обязательно ГОСТ. Главное поставить.
Вова, смысл в том, что ГОСТ ты можешь поставить сам в добровольном (принудительном) порядке, чтобы, к примеру, пользоваться госуслугами или nalog.ru.
И это может происходить централизованно по всей стране.
Это не то же самое, что если злоумышленник как-то обойдёт защиту и как-то установит сертификат.
Вова @JustMoose Автор вопроса
Василий Банников, Так. Вот я добровольно поставил корневой ГОСТовый серт, чтобы ходить на какой-нибудь сайт банка. Но какое к этому имеет отношение MITM и ФСБ?
Вова, отношение имеет такое, что ФСБ имеет прямой доступ к корневым гостовским сертификатам, так как их выпускает, в основном, ФНС/Ростелеком/Минцифры.
А значит они легко могут устроить тебе mitm и расшифровать все данные.
Причём на абсолютно любом сайте, а не только на сайте условного банка.
Вова @JustMoose Автор вопроса
«ФСБ имеет прямой доступ к корневым гостовским сертификатам. А значит они легко могут устроить тебе mitm и расшифровать все данные. Причём на абсолютно любом сайте. «
Прости, всё ещё не понимаю. Формально, доступ к любому корневому сертификату имеет вообще кто угодно. Просто потому, что браузер, заходя на сайт по https, получает сертификат сайта, вместе с корневым (ну или корневой уже стоит в системе). Это просто набор чисел, который пересылается по сети.
Кажется, не хватает каких-то условий.
Или имелось в виду, что у майора есть доступ не только к сертификату, но и к приватному ключу, который к этому сертификату прилагается (что, кажется, позволяет как расшифровать траффик, так и сгенерировать новый серт для нужного сайта)?
Вова, да, речь про приватный ключ
Или имелось в виду, что у майора есть доступ не только к сертификату, но и к приватному ключу, который к этому сертификату прилагается (что, кажется, позволяет как расшифровать траффик, так и сгенерировать новый серт для нужного сайта)?
PKI (система публичных сертификатов) — структура иерархическая. Корневым сертификатом подписываются сертификаты крупных УЦ, дальше они ими могут подписать свои сертификаты второго уровня или сертификаты промежуточных УЦ. Цепочка может, в теории, быть очень длинной, и браузер обязан проверить подписи по иерархии вплоть до корневого.
Проблема с установкой левого корневого сертификата (к сожалению, к левым нужно отнести и серты от госструктур некоторых государств) в том, что браузер будет доверять всему, что происходит от него по иерархии. Т.е. помимо абсолютно легитимной подписи сертификатов для государственных сайтов или банков, таким сертом можно подписать сертикат карманного УЦ товарища майора. А дальше он может с ним делать, что хочет, например, он каждому провайдеру выдаст УЦ и обяжет провайдера при обращении клиента к сайтам по SSL генерить на лету поддельный сертификат для таких сайтов (приватный ключ при это будет провайдерский, трафик провайдер, конечно, сможет расшифровать и передать, куда следует).
смысл в том, что ГОСТ ты можешь поставить сам в добровольном (принудительном) порядке, чтобы, к примеру, пользоваться госуслугами или nalog.ru.
кстати, практически нигде в РФ этого реально не видел. Для физлиц все госсайты и банки имеют обычные ssl сертификаты (может понадобиться свой личный сертификат ЭП, но он никак не связан с установкой корневого в систему).
Единственное, где я встречал такое — на сайте Минпромторга для оформления лицензий (non-tariff.gov.ru)
Или имелось в виду, что у майора есть доступ не только к сертификату, но и к приватному ключу, который к этому сертификату прилагается
Да, это я и имел в виду. Думал, что это понятно.
кстати, практически нигде в РФ этого реально не видел
Да, тоже не видел. Но нельзя исключать, что такое может когда-то произойти.
Вова @JustMoose Автор вопроса
Спасибо, парни. Было очень увлекательно!
galaxy, для физ лиц пока все ок. но для юриков, тот же ЛК сайта казначейтсва, или ЕГАИС(чтоб он сдох) или еще куча гос структур — всё требует поставить левый серт))
Василий Банников, глобалсигн как раз таки этого не делал, отозвали только конторы, подконтрольные digicert’у
Alexander Kalinin, оу, значит перепутал.
Ответы на вопрос 5
CityCat4 @CityCat4 Куратор тега Цифровые сертификаты
Внимание! Изменился адрес почты!
Вся система PKI — она иерархична и построена на доверии. Больше ни на чем. Только на доверии, которое достаточно один раз обмануть, чтобы перестать доверять системе в целом.
Есть некое множество контор, которые выпускают SSL-сертификаты. Они не самые лучшие и не самые правильные, просто однажды они собрались и решили замутить бизнес. Почему все доверяют им? Да просто потому что до недавнего времени не было поводов их обвинить в мошенничестве — там все в порядке (было) с «внутренней полицией», которая нарушителей выкидывала нафиг с пляжа.
Ну и — самое главное — все доверяют им, потому что их корневые сертификаты размещены в хранилищах корневых сертификатов у Windows и Mozilla (Google использует хранилище Windows).
Никакой исключительности — просто тупой договорняк размером с мир. Но, поскольку всегда есть возможность поместить в хранилище корневых (кроме как в андроиде, который сразу же начинает визжать «аааа, меня контролирует Большой Брат!») свои собственные сертификаты — эта схема всех устраивала.
Пока ребята не решили выстрелить себе в ногу, прекратив выпуск сертификатов в зонах .ru/.su/.by/.рф просто по политическим мотивам. Их право — частный бизнес — он такой частный бизнес. Но тут все резко как-то вспомнили, что все «мировые удостоверяющие центры» вовсе нифига не мировые, а просто кучка самозванцев.
И будут у нас скоро госСA, госсертификаты, госбраузеры и все прочее в порядке импортозамещения.
Теперь о том, как проверяется валидность сертификата. А проверяется она очень просто — если сертификат выпущен CA, который находится в списке доверенных — он валидный.
Ты можешь развернуть свой CA, поместить его сертификат в хранилище корневых у себя на компе — и все сертификаты, выпущенные им — для тебя — станут валидными. Выпускай хоть для vk.com, хоть для whitehouse.gov.
И вот именно поэтому все так боятся поместить в хранилище корневых сертификат от какого-нибудь госСA — потому что все сертификаты, выпущенные им система будет считать валидными! Она не делает разницы между сертификатом от Thawte и от «Товарищ Майор Inc.» — она примет сертификат и от того, и от того. А товарищ майор, получив возможность выпускать сертификаты, валидные в Вашей системе, будет выпускать их на ходу и подсовывать их вместо «настоящих», получая доступ к сессионным ключам и таким образом расшифровывая https-трафик (что собственно Fiddler и делает)
Зачем нужен пользовательский и корневой сертификат отличие
Для того, чтобы обеспечить эти требования, все открытые ключи хранятся и передаются в виде сертификатов.
Сертификат — это набор данных специального формата, содержащий сам открытый ключ и всю информацию о нем: кто владелец, адрес электронной почты владельца, когда ключ создан, назначение ключа (подпись или обмен), для какого алгоритма предназначен ключ и т.д.
Сертификаты являются основным инструментом, которым пользуются различные приложения для криптографической защиты информации. В отличие от секретных ключей, криптопровайдеров и прочих составляющих системы криптографической защиты, которые «неочевидны» пользователю, с сертификатами пользователю непосредственно приходится иметь дело при любых операциях, связанных с защитой информации. Поэтому пользователю необходимо знать, как и для чего используются сертификаты, и уметь с ними работать.
Удостоверяющие центры
Создает (выпускает) сертификаты специальный административный центр, называемый удостоверяющим центром (УЦ) или центром сертификации (ЦС).
Удостоверяющий центр устанавливает определенные требования к работе пользователей. Например, удостоверяющий центр определяет максимальный срок действия сертификатов, совокупность необходимых данных запросе на сертификат, способы передачи запроса от пользователя в УЦ, способы проверки корректности запросов пользователей и т.д.
Совокупность требований удостоверяющего центра называется регламентом удостоверяющего центра.
Удостоверяющий центр имеет собственные ключи подписи и подписывает на них все электронные документы, которые он выпускает.
Удостоверяющий центр выпускает сертификат на собственный открытый ключ. Такой сертификат называется сертификатом удостоверяющего центра.
Таким образом, каждый пользователь в любой момент может, воспользовавшись сертификатом удостоверяющего центра, проверить корректность любого сертификата.
- Пользователь создает ключевую пару (открытый и закрытый ключи).
- Пользователь отправляет в удостоверяющий центр запрос на сертификат, в который включает открытый ключ и всю необходимую информацию о себе и о ключах. Набор необходимых сведений определяется регламентом удостоверяющего центра, но всегда необходимо указывать имя владельца, назначение ключей, дату создания.
- Удостоверяющий центр получает запрос и проверяет его подлинность и корректность. Как именно это делается, определяется регламентом удостоверяющего центра.
- Если результат проверки запроса положительный, удостоверяющий центр создает сертификат на открытый ключ, подписывает его, заносит в свою базу данных и отправляет пользователю.
- Пользователь получает сертификат и устанавливает его у себя в системе.
Удостоверяющий центр и пользователи, чьи сертификаты зарегистрированы в удостоверяющем центре, вместе составляют криптосеть.
Криптографические операции и цепочки доверия
Понятие «Проверка подписи» подразумевает проверку соответствия подписи документу, который подписан этой подписью. Если подпись соответствует документу, документ считается подлинным и корректным.
Для проверки подписи используется открытый ключ подписи автора подписи. Но для того, чтобы результат проверки можно было считать надежным, необходимо удостовериться, что сам открытый ключ подписи автора подписи, имеющийся у проверяющего, корректен.
Для этого проводится проверка сертификата на этот ключ. Понятие «проверка сертификата» означает проверку подписи под этим сертификатом. Подпись под сертификатом проверяется на открытом ключе того, кто создал и подписал сертификат — т.е. на открытом ключе удостоверяющего центра.
Т.е. для того, чтобы результат проверки подписи под документом можно было считать надежным, кроме собственно проверки подписи и проверки сертификата на ключ подписи необходимо удостовериться также и в корректности сертификата удостоверяющего центра.
Таким образом, в процессе проверки подписи возникает цепочка сертификатов, каждый из которых проверяется на следующем. Такая цепочка сертификатов называется цепочкой доверия.
То же самое происходит и при зашифровании: прежде чем зашифровать сообщение для владельца открытого ключа обмена, необходимо удостовериться, что данный открытый ключ обмена корректен и подлинен. Для этого необходимо проверить подпись под сертификатом на этот ключ, и возникает точно такая же цепочка доверия.
Корневые сертификаты удостоверяющих центров
В каждой цепочке доверия рано или поздно встречается сертификат, на котором цепочка заканчивается. Т.е. для этого сертификата нет сертификата, на котором его можно было бы проверить.
Такие сертификаты называются корневыми.
Очевидно, что корневым сертификатом в цепочке доверия всегда является сертификат удостоверяющего центра (хотя необязательно каждый сертификат удостоверяющего центра будет корневым—могут, например, существовать сертификаты удостоверяющего центра, подписанные на корневом и т.д.)
Проверить такой сертификат электронными средствами невозможно. Для проверки этих сертификатов используются бумажные распечатки, содержащие определенную информацию: как правило, так называемые цифровые отпечатки, либо сами открытые ключи. Какая именно информация используется для проверки, зависит от регламента удостоверяющего центра.
Цифровой отпечаток документа — это последовательность символов, соответствующая документу таким образом, что каждому документу соответствует свой отпечаток, и по изменению документа нельзя определить, как изменится цифровой отпечаток. Таким образом, можно быть уверенными, что если цифровой отпечаток документа соответствует документу, документ подлинный и корректный. (Эта идея заложена также в основе формирования ЭП).
Для проверки корневого сертификата удостоверяющего центра необходимо получить в удостоверяющем центре бумажную распечатку, содержащую цифровой отпечаток этого сертификата либо открытый ключ, и заверенную подписью администратора удостоверяющего центра и печатью удостоверяющего центра, и сравнить информацию из распечатки с соответствующей информацией, содержащейся в сертификате (увидеть эту информацию можно при просмотре и при установке сертификата).
Если цифровой отпечаток или открытый ключ в распечатке и в сертификате совпадает, корневой сертификат считается корректным. Если цифровой отпечаток или открытый ключ в распечатке и в сертификате не совпадают, значит, файл корневого сертификата искажен. О факте искажения файла сертификата следует немедленно сообщить в удостоверяющий центр—это может означать компрометацию ключей удостоверяющего центра.
Промежуточные сертификаты удостоверяющих центров
Промежуточные сертификаты удостоверяющих центров—это сертификаты на ключи удостоверяющих центров, не являющиеся корневыми. Т.е. это сертификаты удостоверяющих центров, подписанные на других сертификатах удостоверяющих центров.
- Если удостоверяющий центр по какой-то причине (например, окончание срока действия сертификата) создал новые ключи, выпустил сертификат на них и подписал его на старом сертификате;
- Если ключи удостоверяющего центра заверены на ключах какого-то другого удостоверяющего центра. Такая схема удобна, например, для небольших удостоверяющих центров, обслуживающих небольшое количество абонентов. Такие удостоверяющие центры могут заверить свои ключи на сертификате крупного, хорошо известного и пользующегося доверием удостоверяющего центра, корневой сертификат которого установлен у многих пользователей.
Если в цепочке доверия присутствует промежуточный сертификат удостоверяющего центра, она оказывается трехзвенной:
Корневой сертификат УЦ—промежуточный сертификат УЦ—сертификат пользователя.
Более длинные цепочки (с несколькими промежуточными сертификатами) возможны, но встречаются очень редко.
Запрос на сертификат на открытый ключ
Для того чтобы удостоверяющий центр выпустил сертификат на открытый ключ пользователя, пользователю необходимо отправить в удостоверяющий центр запрос на этот сертификат.
Точный набор данных, включаемых в запрос, определяется регламентом удостоверяющего центра. В запрос обязательно включается имя пользователя, назначение запрашиваемого сертификата (подпись или обмен), а также сам открытый ключ, на который создается сертификат. Таким образом, к моменту формирования запроса открытый ключ уже должен существовать.
- У пользователя еще нет ключей. В этой ситуации перед формированием запроса ему необходимо создать ключи.
- У пользователя есть ключи, но срок действия соответствующего сертификата истек. В этой ситуации можно:
- Создать запрос на новый сертификат на имеющиеся ключи. Новых ключей создавать не надо;
- Создать новые ключи и сформировать запрос на сертификат на эти ключи.
Конец срока действия сертификата
Каждый сертификат имеет ограниченный срок действия. Конкретный максимальный срок действия сертификата устанавливается регламентом УЦ, но обычно он не превышает одного года.
По истечении срока действия сертификат становится недействительным.
По истечении срока действия сертификата удостоверяющего центра необходимо получить и установить в системе новый.
По истечении срока действия сертификата на открытый ключ пользователя необходимо сформировать запрос на новый сертификат.
Это может быть запрос на сертификат на уже существующие ключи или на новые ключи. Можно ли получать новые сертификаты на уже существующие ключи или необходимо создавать новые ключи после окончания срока действия сертификата, определяется регламентом удостоверяющего центра.
Отзыв сертификата
Существует ряд причин, по которым действие сертификата бывает необходимо прекратить до окончания его срока действия.
- Компрометация соответствующего закрытого ключа. Если несанкционированный доступ к закрытому ключу все же имел место или обнаружена хотя бы возможность такого доступа, закрытый ключ, а также парный к нему открытый считаются скомпрометированными. Работать с такими ключами нельзя.
- Замена сертификата (например, в связи с изменением адреса электронной почты пользователя).
- Задержка действия сертификата.
В таких ситуациях удостоверяющий центр отзывает соответствующий сертификат.
Если владелец ключей считает нужным отзыв имеющегося у него сертификата, ему необходимо сообщить об этом в удостоверяющий центр. Особенно это важно при компрометации ключей. Если владельцу ключей становится известно о факте их компрометации, ему необходимо сообщить о факте компрометации в удостоверяющий центр как можно скорее.
Удостоверяющий центр отзывает соответствующий сертификат, т.е. заносит его в так называемый список отзыва сертификатов (CRL — Certificate Revocation List). Все сертификаты, числящиеся в списке отзыва сертификатов, недействительны. Список отзыва сертификатов доводится до сведения всех пользователей в соответствии с регламентом удостоверяющего центра.
Владелец отозванного сертификата отправляет в удостоверяющий центр запрос на новый сертификат. Необходимость создания новых ключей в этом случае определяется конкретной ситуацией: если старые ключи скомпрометированы, необходимо создать новые; если речь идет о замене сертификата вследствие изменения актуальной информации о владельце, достаточно создать запрос на новый сертификат на имеющиеся ключи.
Для того чтобы быть полностью уверенным в подлинности и корректности подписи под сообщением, необходимо проверить, не отозван ли сертификат на ключ, на котором выработана проверяемая подпись, т.е. не включен ли этот сертификат в список отзыва сертификатов.
Для чего и где применяется SSL-сертификат?
«На небе только и разговоров, что о море. ». А в интернете — об SSL-сертификате. Что это и зачем? Разберемся здесь и сейчас.
Для чего необходим SSL-сертификат
Наверняка вы замечали, что адреса некоторых сайтов начинаются буквами http, а некоторые — https. И то, и другое указывает на протокол передачи данных, то есть ряд правил, по которым браузер и сервер обмениваются информацией.
Передача данных по протоколу http происходит в открытом виде. Рассмотрим на примере: когда вы покупаете что-то онлайн и вводите данные банковской карты, браузер сообщает их серверу. Если сайт работает по http-соединению, данные, которые вы указали, никак не защищены, а это значит, что злоумышленник может получить к ним доступ и расплатиться вашей картой в интернете.
Чтобы таких ситуаций не происходило, было создано специальное расширение для протокола http, отвечающее за защиту передаваемых данных — https. Чтобы эту защиту обеспечить, данные необходимо зашифровать — вот для чего нужен SSL-сертификат.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостейКак работает SSL-сертификат
Вернемся к нашему примеру с заказом в интернет-магазине. Если вы вводите данные своей карты на сайте, который защищен сертификатом, браузер превращает эти данные в случайный набор символов, и в таком виде сообщает их серверу. Расшифровать такое «послание» можно только с помощью ключа, который хранится на сервере. Ключ сложный и состоит из множества символов, так что подобрать его — задача непосильная. А это значит, что при таком способе передачи информации ваши личные данные надежно защищены от злоумышленников.
Обращать внимание на наличие сертификата на сайте стоит не только тогда, когда вы там что-то покупаете. Если вы регистрируетесь, оставляете свой e-mail или номер телефона, проследите, чтобы рядом с адресом сайта отображался «замочек», как на скриншоте ниже, а не сообщение «Не защищено».
Когда мы разобрались, зачем сайту нужен SSL-сертификат, узнаем, что он из себя представляет. «Физически» это набор файлов, который формируется следующим образом:
- Создается запрос, содержащий информацию о домене и будущем владельце сертификата — Certificate Signing Request (CSR), в переводе означает «запрос на подпись сертификата», а также называется публичным ключом.
- CSR отправляется Центру сертификации (Certificate Authority, CA).
- CA выпускает сертификат на основе данных в запросе и предоставляет свои промежуточные и корневой сертификаты.
- На сервере, где был создан CSR, формируется приватный ключ.
- Ваш сертификат + сертификаты доверенного центра + приватный ключ + ваш сайт = безопасное соединение.
Когда на сайте есть сертификат, вы можете увидеть, кому он выдан, кем выдан и до какой даты действует. Нужно кликнуть «по замочку» и нажать «Посмотреть сертификат».
Подведем итог простыми словами: SSL-сертификат приобретается для доменного имени, а устанавливается там, где вы покупаете хостинг для сайта. Заказать сертификат обычно можно там же, где и хостинг, например, в Timeweb, что очень удобно.
Если вы уже установили сертификат, но сайт открывается по незащищенному протоколу http, нужно настроить перенаправление с http на https — на стороне хостинг-провайдера, где размещен ваш сайт. Тогда при переходе на сайт будет сразу устанавливаться безопасное соединение. При этом важно, чтобы все элементы на сайте передавались по защищенному протоколу, иначе возникнет ошибка «mixed content» (означает «смешанное содержимое»). Что это такое, хорошо описано в статье «Чем опасна ошибка смешанного контента на сайте».
Виды SSL-сертификатов
Какие бывает SSL-сертификаты, в двух словах не рассказать, так как есть несколько критериев, по которым их можно классифицировать. Начнем с самоподписанных и доверенных.
Самоподписанный сертификат можно выпустить самостоятельно при наличии нужных инструментов. К примеру, это доступно в некоторых панелях управления веб-сервером (ISPmanager, Cpanel и т.д.). Из хорошего здесь то, что такой сертификат бесплатный, из плохого — его можно использовать только для служебных целей, а вот доверие посетителей сайта он не вызывает, потому что в адресной строке сообщается «Не защищено». Иначе говоря, сайт выглядит точно так же, как и если бы у него не было сертификата.
Доверенный сертификат выпускается Удостоверяющим центром — организацией, обладающей правом на выдачу сертификатов. Из всего того, что дает такой SSL-сертификат, стоит выделить самое важное: для посетителей сайта — это гарантия безопасности, а для его владельца — доверие пользователей. Википедия определяет Центр сертификации как «сторону, чья честность неоспорима». Вот несколько тому объяснений:
- Проверка на право владения доменным именем или информации о компании, которая запрашивает сертификат.
- Высокий уровень шифрования данных, подкрепленный финансовой гарантией.
- Цепочки корневых сертификатов доверенных центров по умолчанию включены практически во все браузеры.
Эти преимущества в большей степени относятся к коммерческим Центрам сертификации (к примеру, Sectigo). Существуют также бесплатные, самым популярным является Let’s Encrypt.
Чем отличаются бесплатные SSL-сертификаты от коммерческих: обычно методы шифрования и тех, и других центров соответствуют актуальным стандартам, но бесплатные не предоставляют финансовую гарантию, такие сертификаты могут не поддерживаться некоторыми браузерами и операционными системами и имеют небольшой срок действия (как правило, 90 дней).
Также сертификаты можно разделить, основываясь на способе проверки:
- DV, Domain Validation — сертификат, подтверждающий доменное имя. Его можно получить за 15 минут, так как Центр сертификации проверяет только право владения доменом.
- OV, Organization Validation — сертификат, подтверждающий домен и существование организации. При его выпуске, помимо права на домен, CA проверяет и регистрацию компании. Для получения такого SSL-сертификата понадобится несколько дней.
- EV, Extended Validation — сертификат, подтверждающий принадлежность сайта компании. Перед тем, как его выпустить, Центр сертификации проводит тщательную проверку — от права на домен до лицензии на вид деятельности, в среднем это занимает от нескольких дней до двух недель. Заказ открыт только юридическим лицам.
Раньше отличительной чертой EV являлась не только особая проверка, но и отображение этого сертификата на сайте — в адресной строке браузера было закреплено название компании и обозначено зеленым цветом.
Буквально недавно произошло изменение, и название компании было перенесено «под замочек». Нужно нажать на него, чтобы посмотреть информацию. Обновление вступило в силу в новых версиях некоторых браузеров: Chrome 77, Firefox 70, Safari на iOS 12 и macOS 10.14.
Как уже упоминалось выше, сертификат заказывается для доменного имени. А что делать, если нужно защитить и домен, и поддомены? Или сразу несколько разных доменных имен? Нужен ли отдельный SSL-сертификат каждому субдомену или домену?
Если вы используете и домен, и субдомены, стоит обратить внимание на SSL Wildcard. Этот сертификат распространяется на основной домен, а также его поддомены уровнем ниже. Он дороже сертификатов, предназначенных для одного домена, так что имеет смысл в его покупке, когда субдоменов много. Если же 1-2, то выгоднее заказать сертификаты отдельно для каждого.
В ситуации, когда у вас много онлайн-проектов на отдельных доменах, поможет SAN SSL, который защищает сразу несколько доменов (также его называют мультидоменным сертификатом). Его цена зависит от количества доменов, для которых он предназначен.
Каким сайтам необходим SSL-сертификат
Отсутствие сертификата недопустимо на сайтах, где совершается оплата и хранятся персональные данные пользователей: интернет-магазины, банки, платежные системы, социальные сети и т.д. Нужен ли SSL-сертификат обычному сайту? Например, личному блогу, сайту-визитке, корпоративному сайту или тематическому форуму. Скорее, да. Даже если на вашем сайте не нужно ничего покупать или регистрироваться, надпись «Не безопасно» может отпугнуть посетителей. Когда «замочек» в адресной строке, напротив, вызывает доверие пользователей. Предпочтение сайтам, защищенным сертификатами, отдают и поисковые системы Яндекс и Google, повышая их в выдаче.
Важно понимать, что сертификат отвечает за защиту передаваемых данных, но не может обезопасить сам сайт от взлома, вирусов или DDoS-атаки. Бороться с этими «вредителями» нужно другими методами. Рекомендации на случай таких ситуаций вы можете найти в Community.