Когда сертификат вызван в действие, роль, которую он призван выполнять, так же важна, как и идентификация. Речь идет не только о личности, но и о роли авторизации. Сертификат защиты электронной почты не должен быть в состоянии выполнить проверку подлинности сервера. Проблемы безопасности диктуют необходимое ограничение полномочий, предоставляемых одним сертификатом. Базовый API должен обеспечивать правильное использование, будь то через ОС или абстракцию, например .NET Framework.
Существуют разные типы сертификатов, поскольку в аутентификации и авторизации очень разные роли, которые могут понадобиться. Разрешение различных типов сертификатов и иерархий позволяет моделировать цепочки сертификатов, как указано в «Пути сертификации» сертификата. Сертификат проверки подлинности сервера должен иметь сертификат CA верхнего уровня где-нибудь в доверенных корневых сертификатах ... или быть частью семейного дерева сертификатов, что в конечном итоге имеет место. Я уверен, что сторонние центры сертификации оценивают их по функциональности и доверию.
Boot To The Head правильно ... есть атрибут Enhanced Key Usage, который предоставляет описание того, какой сертификат претендует на роль (например, аутентификация на сервере или в случае моего CA) сертификат: цифровая подпись, подпись сертификата, автономная подписка CRL, подпись CRL). Посмотрите детали в свойствах сертификата, и вы найдете его.