Различающееся имя субъекта (DN субъекта) представляет собой упорядоченную последовательность относительных различающихся имен (RDN), и каждое RDN является неупорядоченным набором утверждения значения атрибута (AVA).AVA - это что-то вроде «CN = ваше имя» или «O = ваша организация» (хотя они не хранятся в сертификате).
В большинстве случаев будет только один AVA на RDN,поэтому, если это не странный случай, часто допустимо называть это CN RDN субъектного DN, например (или даже «полем», я полагаю, если вам не нужно быть слишком конкретным).Существует несколько стандартов для сериализации DN субъекта в читаемую строку, в частности слева направо или справа налево, или E= против emailAddress=, или разделитель запятой или косой черты.Сначала вы должны убедиться, что ваш инструмент может прочитать их из их OID (Идентификатор объекта), а не из строкового представления.
Часто последовательность будет состоять из страны, организации, организационной единицы, общего имени и, возможно, электронного адреса.почта (хотя адрес электронной почты всегда проблематичен, поскольку он один из тех, которые не всегда сериализуются в строку одним и тем же способом в зависимости от используемого стандарта).
В целом, центры сертификации могут делать то, что нужноони хотят с точки зрения структуры DN субъекта и того, используют ли они альтернативные расширения имени субъекта.Эти вещи, как правило, регулируются каждой политикой CA (это могут быть довольно длинные технические и юридические документы).В этом домене нет единого размера.
Прежде чем принимать клиентские сертификаты, убедитесь, что вы согласны с их политиками.Если вы доверяете сертификату CA, модель PKI становится такой, что после этого трудно сделать точный выбор.
Список доверенных CA зависит от платформы и конфигурации.По умолчанию Java в OSX имеет около 150 сертификатов CA в своем хранилище доверенных сертификатов, на других платформах это около 70, я думаю.Эти цифры могут существенно различаться.
В любом случае, если вы действительно хотите принимать клиентские сертификаты, вам более или менее необходимо знать, откуда они берутся, поэтому довольно часто у вас будет небольшое подмножество CA, которые вы используете.готовы доверять этому.Я бы определенно рекомендовал настроить, какие центры сертификации вы хотите доверять для аутентификации по сертификату клиента после тщательного выбора вручную (на основе документов политики).
На практике я не уверен, почему клиенты будутотправьте свой сертификат случайным образом на любой сервер, просто так.PKI для клиентских сертификатов, как правило, лучше работают в закрытом административном домене или в устоявшейся федерации, и в этом случае вы и ваши пользователи будете принадлежать к этим организациям, и вы будете знать, какой CA ожидать.Кроме того, я бы предложил ограничить использование клиентских сертификатов для аутентификации пользователя, одновременно выбирая дополнительные атрибуты откуда-то еще, например, с сервера LDAP.Как правило, клиентские сертификаты будут выдаваться физическому лицу в течение года или более, тогда как информация о человеке (даже организационной единице) может измениться на практике.Все это необходимо учитывать, если вы хотите использовать ЦС или настроить свой собственный.