Доброго времени суток!

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

Здравствуйте, Аноним, Вы писали:

А>Доброго времени суток!

А>Есть список сертификатов для https-авторизации, установленных в браузер. Каким образом он (браузер), определяет какой сертификат какому сайту принадлежит?

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

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

Здравствуйте, Kubyshev Andrey, Вы писали:

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

а если в качестве хоста будет только wildcard — '*' то браузер это проглотит и позволит с данный сертификат к любому хосту привязать? мне просто неохота эту гипотезу проверять через makecert сертификаты

P>а если в качестве хоста будет только wildcard — '*' то браузер это проглотит и позволит с данный сертификат к любому хосту привязать?

Такой сертификат вам никто не выпишет.
Разве что будете собственный CA организовывать и сами себе подписывать сертификаты. Но в этом случае не вижу проблем наподписывать любое количество любых сертификатов.

свой CA не нужен — достаточно установить 1 self signed root ca сертификат в Windows Trusted Roots сертификаты или в браузер, после этого браузер не станет выдавать предупреждений. просто тут если браузер может на основе сертификата с хостом '*' авторизовать любой хост, и заранее известно что CA такой серт не выдаст, то значит что этот браузер специально сделал такое security hole для selfsigned сертификатов, чтобы угодить CA вендорам — повысить их надежность в глазах пользователя. в большинстве случаев достаточно по отпечатку(thumprint) его авторизовать, а информацию об отпечатке можно зашить например в QR код или webconfig

* выдает host mismatch name ошибку, так что это не рабочий вариант

Возьмите персональный сертификат webmoney. В нем нет никаких хостов. И subj'ы не совпадают. Каким образом браузер определяет, что для входа на https://light.wmtransfer.com требуется именно этот сертификат?

При ssl-хэндшейке, в случае авторизации клиента, сервер передает клиенту запрос request_client_certificate, который содержит цепочку DN'ов подходящего сертификата. Но опять же, если брать сертификат от webmoney, то ни один из переданных сервером DN'ов не подходит под сертификат.

тут еще кстати часто путают понятия self signed certificate. selfsigned это когда поля issuer и subject совпадают, а не selfsigned это когда имеется selfsigned root ca, в этом случае будет цепочка из 2 сертификатов во главе которой selfsigned root ca. selfsigned вариант вообще подвержен MIDM атакам тк его можно подменить 2 способами — создать сертификат с таким же subject полем или востановить приватный ключ через утилиту 'certutil'. а для 2 варианта приватный ключ через утилиту 'certutil' уже не восстановишь если нет доступа к selfsigned root ca, так что его можно смело авторизовать по полям thumprint rootca и самого сертификата тут вроде security основана на сопротивляемости sha1 алгоритма к повторам, тк воспроизвести сертификат с таким же отпечатком не получится.

Здравствуйте, pavel783, Вы писали:

P>а если в качестве хоста будет только wildcard — '*'

Так нельзя