Comments 21
Два бокала этому господину!
У вас настоящий талант объяснять. Хотелось бы видеть как можно больше статей от вас.
Замечательное резюмирование.
Специально восстановил пароль с 2014 года, чтобы плюсануть. (правда, не могу, т.к. нет кармы, поэтому похвалю текстом). Это лучшая статья по теме, которую я бы хотел прочесть много лет назад. Гуглил, собирал из источников, но такого логически связанного, подробного и понятного описания в одной статье не находил. Плюс стиль изложения и "Mother-in-the-middle attack" :) Шикарно! Пишите ещё и побольше! Спасибо!
Не знай почему у вас ассоциация, что "корневой" это самоподписанный. Когда даже при просмотре сертификатов он просто последний в цепочке.
Что значит "последний"?) Допустим, цепочка сертификатов выглядит так: A->B->C->D, где A самоподписанный, а D листовой. Если сертификат A доверенный для моего браузера, тогда согласен, что он последний в цепочке, он же корневой. А если доверенным является B, но не A? Я бы всё ещё сказал, что последним в цепочке является А, тем не менее, мой браузер не считает его корневым в общепринятом смысле.
Даже если считать, что тогда последним в цепочке является B, а что если во втором браузере у меня B не доверенный, а доверенный C? Получается, нужно говорить о сертификате "корневом для данной программы". По-моему эта фраза звучит очень странно. Для меня "корневой" слышится как какое-то неотъемлемое свойство сертификата или CA, а по факту "корневость" сертификата зависит от конкретной программы. Короче, как ни крути, какие-то неоднозначности.
В данном случае корневой в цепочке это А, потому что дальше него никого нет. И цепочка подписывания сертификатов, от программ их использующих, никак не зависит. Если в твоей системе вся цепочка будет не доверенная, то от этого "пропадания" корневого сертификата не произойдёт.
Может быть A и последний в цепочке, но в общепринятом смысле корневым здесь будет B. Сама цепочка от приложения не зависит, но какой сертификат в ней доверенный, то есть на каком приложение закончит (если закончит) проверку цепочки, зависит.
Взять конкретно: вот я с помощью OpenSSL создал себе эту цепочку сертификатов A->B->C->D, запустил сервер, использующий сертификат D, и открываю страницу на винде в ms edge. Для этого я добавил сертификат B в хранилище сертификатов "Trusted Root Certification Authorities" на винде. То есть, судя по по названию хранилища, теперь B корневой, но на нём цепочка не заканчивается.
Многие другие приложения вообще избегают слов "корневой" и "доверенный". В Firefox список сертификатов называется просто "authorities", в curl они передаются в опции "-cacert" и в документации не упоминаются слова "root" и "trusted". В nodejs проскальзывает "root", но документация его использует очень осторожно, и переопределяется список сертификатов опцией просто "ca".
Возможно надо microsoft винить за некорректное название хранилища на винде конкретно. Но, надеюсь, видите, какая с этим словом путаница
Ваша статья как нельзя вовремя, потому что мне сейчас очень нужно разобраться с работой сертификатов по своим задачам. Спасибо большое!
Клиент и сервер генерируют ключи DH и данные DH, обмениваются последними по незащищённому соединению... В этом и есть очень большая проблема в шифровании...
Не понял а где в этих картинках вот это:
В какой момент происходит запрос в центр сертификации для проверки что сертификат сервера(сайта) действителен?
Serial Number — серийный номер. Нужен, например, чтобы отзывать сертификаты. Как это делается описывать не буду: задача нетривиальная.
К сожалению, не вместилось в статью. А может и не к сожалению, не считаю эту тему особенно интересной)
Возможно что ни в какой. Это опционально. Кроме того, есть протоколы CRL и OCSP, и если второй используется именно для получения статуса конкретного сертификата, то первый предполагает получение списка отозванных. Который можно получать скажем раз в сутки, и дальше пользоваться. Ну т.е. к вашему вопросу — при установлении соединения запроса в центр может и не быть, потому что применяется CRL, и потому что список запросили в прошлый раз.
Как это не в какой? например хабр. Что будет если я сейчас выключу компьютер и включу в 2024 году? Допустим даты окончания находятся внутри сертификата, и хабр его обновит. Значит при заходе на сайт , я должен буду скачать новый сертификат, значит будет запрос?
Как я понимаю (поправьте):
1) вызываю в 2024 https://habr
2) устанавливается TLS соединение по 443 порту я прокидываю к нему хэш сертификата, сервер говорит НЕНЕНЕ уже новый! И отдает новый сертификат
3) после этого хром с этим сертификатом устанавливает соединение с https://CENT_SERTIFIKACHII и спрашивает это хороший сертификат? Ответ допустим да.
4) TLS соединение продолжается и с новым сертификатом
5) при следующих запросах к habr пункт 3 не выполняется до истечения срока годности.
Вы не путаете даты окончания действия (которые есть в самом сертификате, и для их проверки никакой запрос никуда не нужен), и статус "отозван", для проверки которого запрос нужен, но не обязателен?
Вы не обязаны проверять сертификат на то, что он отозван. Вы можете это сделать — но не должны. Ощущаете разницу? А дата валидности проверяется конечно, при каждом запросе, но для ее проверки не нужно спрашивать никакой CA.
сделал update предыдущего комментария.
вы сильно привязались к "проверке", я больше про случай когда это произойдет (вероятней всего по логике) например при моём случаи если я зайду в 2024.
Не, ну вот ваш оригинальный вопрос:
запрос в центр сертификации для проверки что сертификат сервера(сайта) действителен?
Сертификат сайта вам отдает сайт, а не центр сертификации. Сертификат самого центра сертификации уже лежит у вас на компьютере. Проверок на действительность — их достаточно много, если упрощенно, то как минимум:
- что дата окончания действия сертификата не прошла
- что сертификат подписан по цепочке каким-то центром сертификации, которому ваш софт доверяет
- что сертификат не отозван
Только для последней проверки нужен запрос куда-то (на самом деле — к сервису CRL или OCSP, и это вообще говоря разные сервисы с центром сертификации). Но сама эта проверка не обязательна.
3) после этого хром с этим сертификатом устанавливает соединение с https://CENT_SERTIFIKACHII и спрашивает это хороший сертификат?
Может хром это и делает, но в общем случае эта проверка не обязательна. То есть, вы можете хоть в каком году обменяться с хабром сертификатами, и если хабр вам отдаст сертификат, срок действия которого не прошел, и который подписан центром сертификации, которому вы доверяете (все это на тот момент) — то все ок. Если вы зайдете в 2024, то у текущего сертификата хабра закончится срок действия — но чтобы это узнать, вам не нужен никакой центр сертификации — вы это узнаете при получении сертификата от сайта. Срок действия — в самом сертификате.
Иными словами, вы изначально спрашивали про запрос к центру сертификации, а потом:
я должен буду скачать новый сертификат, значит будет запрос?
Запрос на сертификат будет к хабру.
Лучше бы вернули маленькие серверочки для не ру сегмента, задины ?
Спасибо за познавательную статью! Маленькое замечание для тех кто захочет повторить практическую часть: у меня OpenSSL (Ubuntu под Win) не захотел генерировать сертификат промежуточного CA без параметра -CAcreateserial.
Разбираем TLS по байтам. Кто такой этот HTTPS?