Я создаю сайт со своим собственным ЦС и подписываю с ним сертификаты клиентов. Клиентам нужно будет добавить мой ЦС в качестве надежного источника, но из соображений безопасности я не хочу, чтобы они слепо доверяли всему, что может быть подписано с помощью ключа ЦС, поэтому я хочу наложить ограничения, чтобы завоевать доверие клиентов. Поэтому я хочу ограничить возможности центра сертификации только подписанием клиентских сертификатов и включением https
доступ. Я не уверен, что все ограничения, которые я должен наложить при создании сертификата.
Лучший способ сделать это кажется Ограничения имени, и используйте белый список, чтобы ограничить использование, то есть очевидно уважаемый в настоящее время. Итак, я должен использовать DNS (скажем, xyz.com), поэтому подпись CA не будет принята для google.com f.ex, и поместите ее также в каждый SAN сертификатов клиента, поэтому сертификаты клиента считается действительным и не отклонено. Видимо, это не так. Я пробовал это, но мне не удалось заставить его работать правильно. Кроме того, я получаю предупреждение от Windows ... Возможно, это потому, что все возможные типы ограничений имени должны присутствовать?
Итак, мои вопросы:
РЕДАКТИРОВАТЬ
В идеале в моем сертификате CA должно быть что-то, что заставляет его подписывать только сертификаты клиентов и выполнять аутентификацию сервера https. Я не понимаю, как сделать это ограничение, думаю, это невозможно.
Для использования ограничений имени я использовал xyz.com
как разрешено, и я думал, что только сертификаты, подписанные моим CA с SAN xyz.com
и фактически используемый с этим именем будет принят (в противном случае я мог бы создать сертификат с SAN xyz.com
и google.com
и может работать при доступе google.com
). Итак, я использовал сертификат клиента, подписанный моим центром сертификации, без SAN. xyz.com
и меня приняли. Не уверен, что ограничения имен применимы и в этом случае.
Есть несколько ограничений, которые вы можете установить в выпускающем сертификате, которые ограничивают количество сертификатов, которые он может подписывать.
Вы уже упомянули о них. Их можно использовать для ограничения того, какие имена могут использоваться в различных альтернативное имя субъекта типы конечного сертификата (внесение в белый список с использованием разрешено) или не могут быть использованы (занесение в черный список с использованием excludedSubtrees). На практике, вероятно, вам нужен первый вариант. Типичный вариант использования - разрешить только адреса электронной почты и dnsNames, оканчивающиеся на одно из доменных имен вашей компании.
Эта страница дает более подробную информацию.
Это расширение может указывать, в соответствии с какой политикой может быть выдан конечный сертификат. Поскольку это не то, что вы действительно можете технически обеспечить (кроме сравнения OID), это не будет вам полезно
Это не совсем стандартное использование, но поскольку ваш снимок экрана показывает, что вы живете в мире Microsoft, он может быть вам полезен. Microsoft изобрела так называемый Политика приложения который позволяет выпускающему сертификату ограничивать использование расширенного ключа, которое может иметь выданный конечный сертификат. Установив для этой политики значение tlsClientAuthentication, вы можете гарантировать, что выдаются только такие клиентские сертификаты, а не сертификаты сервера TLS или сертификаты подписи кода. За пределами космоса Microsoft это расширение, вероятно, будет проигнорировано.
И последнее слово: проверить эти ограничения довольно сложно, большинство программ даже не пытаются их попробовать, и не так много продуктов, которые действительно это делают.