Работа идёт исключительно с хранилищами сертификатов КриптоПро CSP, не с файлами на диске.

Например, CApath = TrustedPeople означает, что у вас есть готовое хранилище сертификатов с именем TrustedPeople, в котором лежат сертификаты пользователей, которым разрешён вход.

Если CApath не указан, проверка пользовательских сертификатов происходит по цепочке до доверенного издателя в штатном хранилище корневых сертификатов root.

Отредактировано пользователем 26 августа 2020 г. 14:28:47(UTC)  | Причина: Не указана

Как интересно. По названию параметра предполагал, что разрешение распространяется на все сертификатов определенного УЦ. А оказывается можно одной группе сертификатов (в указанном хранилище) разрешить вход, а другим сертификатам, выданным тем же УЦ, отказать? Или возможны оба сценария (разрешить всем от одного издателя и разрешить выборочно от одного издателя), тогда как настроить? Зависит от того сертификат УЦ в хранилище или конечный сертификат?

Отредактировано пользователем 27 августа 2020 г. 5:41:00(UTC)  | Причина: Не указана

То есть берется объединение множеств допущенных базовой проверкой и CApath проверкой? Правильно понимаю?

Тогда теоретически можно войти и сертификатами от всех аккредитованных УЦ (когда установлен сертификат Минкомсвязи в корневые) и сертификатами от всех штатных корневых УЦ из поставки Windows. Смысл проверки резко снижается, если можно войти вообще любым действительным сертификатом. Выходит, чтобы работал только CApath надо заведомо "провалить" базовую проверку? Хотелось бы иметь возможность запретить часть прошедших базовую проверку для конкретного соединения. Как минимум запретить не гост-2012 сертификаты из поставки Windows.
Если это тоже работает в дополнение к базовой проверке, то берется пересечение или объединение множеств?
Может поменяться порядок компонент, если сменился экземпляр/шаблоны УЦ (многие аккредитованные УЦ делают новые экземпляры УЦ ежегодно, прекращая выпуск конечных сертификатов на "прошлогоднем" экземпляре). У разных УЦ точно разный порядок компонент. Сертификаты разных назначений также могут отличаться по наличию/порядку некоторых компонент. Отдельная тема про кавычки в наименовании организации - УЦ их кодируют совершенно разными строками. Безусловно, это интересный способ, но от замены строк при смене сертификатов скорее всего не спасет, если не выпускать сертификаты на подконтрольном внутреннем УЦ.

Вопрос по сравнению - должен совпадать весь список в определенном порядке, совпадать весь список в произвольном порядке или возможен поиск по подстроке (отдельному компоненту)? Для отечественных сертификатов поиск исключительно по огрн/снилс/email был бы интересен. Опять же вопрос как компонент огрн/снилс указывать - латинскими буквами, кириллицей или оидом? Если проверка исключительно кодом Майкрософт, то полагаю порядок компонент важен и огрн/снилс указывать оидом или строкой согласно регистрации оида в реестре.