Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 9
Мой вопрос покажется совсем чайниковским, но, уверяю, это не так.
… представляет собой сертификат удостоверяющий принадлежность некоторому субъекту, например, пользователю.Принадлежность чего? Не может же ведь быть «просто принадлежность». Одну сторону отношения «принадлежит» мы обозначили (это у нас пользователь), но что у нас на другой стороне?
Принадлежность приватного ключа, публичная часть которого в сертификате
насколько мне известно сертификаты предназначены в основном для хранения открытых ключей. закрытые ключи в сертификатах редкая и не безопасная опция.
А я разве сказал, что в сертификате закрытый ключ? В сертификате находится открытый ключ, из какого-то источника вы знаете, что он принадлежит Пете. Так как открытому ключу соответствует закрытый, то, подтвердив, что ключ действительно Петин, вы также транзитивно подтверждаете, что приватный ключ из пары открытый-закрытый ключ принадлежит Пете. А значит, шифруя открытым ключом сообщение или проверяя им подпись, вы можете быть уверены, что прочитает его/сгенерировал ее именно Петя, а ни кто иной.
Вторая сторона — открытый ключ.
Который является частью… ну да, сертификата.
Странно получается. По сути, файл с расширением «cer» — это публичный ключ. Этот ключ дополнен подписью удостоверяющего центра, которая подтверждает, что бинарные данные ключа соответствуют описательным полям (субъект, мэйл, то-сё). Но самая мякотка, суть и смысл существования этого файла — всё же ключ. Всё остальное, в том числе подпись УЦ — это дополнительные данные разной степени полезности.
Почему же ключ не назвать ключом? Почему мы стабильно запрягаем телегу впереди лошади? Почему допускаем понятийную путаницу?
Когда генерится ключевая пара, мы имеем два ключа — секретный и публичный. Публичный мы можем снабдить сертификатом соответствия. А можем и не снабжать. Можем снабдить, но оформить отдельным файликом. Почему бы и нет? Заливка ключа и сертификата к нему в один файл — это всего лишь один из возможных вариантов. В том же Биткоине, например, асимметричная криптография используется вовсю, но никаких сертификаций там отродясь нет.
Странно получается. По сути, файл с расширением «cer» — это публичный ключ. Этот ключ дополнен подписью удостоверяющего центра, которая подтверждает, что бинарные данные ключа соответствуют описательным полям (субъект, мэйл, то-сё). Но самая мякотка, суть и смысл существования этого файла — всё же ключ. Всё остальное, в том числе подпись УЦ — это дополнительные данные разной степени полезности.
Почему же ключ не назвать ключом? Почему мы стабильно запрягаем телегу впереди лошади? Почему допускаем понятийную путаницу?
Когда генерится ключевая пара, мы имеем два ключа — секретный и публичный. Публичный мы можем снабдить сертификатом соответствия. А можем и не снабжать. Можем снабдить, но оформить отдельным файликом. Почему бы и нет? Заливка ключа и сертификата к нему в один файл — это всего лишь один из возможных вариантов. В том же Биткоине, например, асимметричная криптография используется вовсю, но никаких сертификаций там отродясь нет.
Тема не раскрыта.
Хочется увидеть пример кода как сформировать сертификат (добавить туда атрибуты и дополнительные поля) и подписать другим сертификатом (к которому есть доверие).
Как проверить валидность сертификата, не отозван ли он.
Хочется увидеть пример кода как сформировать сертификат (добавить туда атрибуты и дополнительные поля) и подписать другим сертификатом (к которому есть доверие).
Как проверить валидность сертификата, не отозван ли он.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Криптография в Java. Класс Certificate