Здравствуйте.
Так не выйдет, надо передавать запрос с субъектом соответствующий профилю пользователя. Переопределять через запрос можно расширения, но не dn.

Судя по описанию вы хотите выпускать сертификаты одному пользователю - TLS и подписи, в рамках ПлЦР?
Решение - передавать все компоненты имени на оба запроса, а что в субъект сертификата попадет - регулировать настройкой шаблона на сертификат.

Вот как вы написали - это звучит как обход лицензионных ограничений.

---

Microsoft-специфичный атрибут:

OID: 1.3.6.1.4.1.311.13.2.1
Имя: szOID_ENROLLMENT_NAME_VALUE_PAIR

Он используется внутри PKCS#10 CSR для передачи дополнительных данных. Эти данные не являются частью Subject и могут содержать совершенно другую информацию. УЦ может использовать их для формирования SAN, выбора параметров сертификата, EOBO и т.д. В вашем частном случае использовать CpRaRequesterProfile для отправки запроса пользователю у которого такой же Profile, но будет работать только если передавать в подписи, а не как атрибут запроса.




При отправке запроса на ЦР проверяется:
1. профиль пользователя и субъект запроса - если есть отличия -> запрос отклоняется.
2. Если в подписи к запросу передавать атрибут CpRaRequesterProfile, то будет сравниваться профиль пользователя с профилем в данном атрибуте -> субъект будет игнорироваться в запросе.

В шаблоне обязательно должно быть указано, как должен быть сформирован субъект сертификата. Эта настройка содержится в объекте SubjectName и заключается в указании источника компонентов имени и правил формирования субъекта: PrioritySource - определяющее приоритет источника данных для формирования субъекта. Может принимать одно из следующих значений:
o Profile - данные для формирования субъекта берутся в первую очередь из профиля пользователя в запросе (атрибут CpRaRequesterProfile), а если профиль отсутствует - то из субъекта
o Subject - данные для формирования субъекта берутся в первую очередь из субъекта запроса, а если субъект не заполнен - то из профиля.



Это реализовывалось, например, когда запрос делает дбо и кладет пустой субъект либо что-то типа DSN=guid, а хочется издать нормальный сертификат.

Подскажите, пожалуйста, что означает этот пункт в документации на УЦ 2.0 1.63.0.32?



Т.е. из шаблона в сертификат могут попадать данные, которые не совпадают с профилем пользователя. PrioritySource = Subject работает через pkica, но через rest-api не получается это использовать, похоже RA требует точного соответствия запроса и пользователя, что делает бессмысленным настройки PrioritySource. Подскажите, пожалуйста, как можно воспользоваться PrioritySource через rest-api? как отключить проверку точного соответствия в RA?