Возможно я наивно упускаю какие-то тонкие моменты, но в принципиальной схеме проблемы не вижу:

• локальный пользователь Иванов создает вне домена настраиваемый запрос, с использованием необходимых oid'ов и т.д.

• Домен админ на основе запроса выпускает на доверенном доменном УЦ сертификат который

- ассоциирует с УЗ Иванова в AD (https://www.sysadmins.lv/blog-ru/autent … ertyj.aspx)

- возвращает сертификат локальному пользователю

• локальный пользователь связывает полученный сертификат с ключевой парой на токене, все счастливы

Добрый день.
Такая схема прекрасно реализуется стандартными средствами Windows. 
1. С помощью оснастки Сертификаты консоли управления mmc на компьютере вне домена создаётся запрос на сертификат: в пустом месте правой кнопкой мыши, далее Все задачи - Дополнительные операции - Создать настраиваемый запрос.
2. Запустится мастер регистрации сертификатов. На 3 странице убедиться, что выбран шаблон Ключ CNG(без шаблона).
3. На следующем шаге раскрыть Подробности и нажать Свойства.
4. На последней вкладке Закрытый ключ выбрать только RSA,Microsoft Smart Caerd Key Storage Provider; ниже в параметрах указать длину ключа.
5. На предыдущей вкладке Расширения включить симметричные алгоритмы в соответствующем блоке.
6. Необходимость указания остальных параметров зависит от настроек шаблонов сертификатов в домене.
7. На следующем шаге система запросит пин-код и место, где сохранить запрос.
8. Зайти на сайт Службы сертификации Active Directory тем пользователем, для которого требуется выдать сертификат. Запрос сертификата - Расширенный запрос сертификата.
9. Вставить текст запроса и выбрать необходимый шаблон сертификата, нажать Выдать и сохранить полученный сертификат.
10. Перенести полученный файл на исходный компьютер. Двойным кликом открыть и установить сертификат, должен запроситься пин-код.
11. Проверить работоспособность полученного сертификата.

Это если кратко.
Однако, есть много индивидуальных моментов на связке запрос-шаблон: что указать в запросе, что задаётся в шаблоне автоматически и что хочется получить в итоге. Например, стандартный шаблон "Smartcard User" берёт из AD поле e-mail и полностью игнорирует заданное в запросе. Выбор криптопровайдера также меняет поведение полученных сертификатов.

[VERSION]
Signature="$Windows NT$

[NEWREQUEST]

X500NameFlags=CERT_NAME_STR_SEMICOLON_FLAG|CERT_NAME_STR_ENABLE_UTF8_UNICODE_FLAG

Subject="CN=Ordinary User;OU=Personel;O=My Organization;C=ZZ"

RequestType=PKCS10

Silent=FALSE

MachineKeySet=FALSE
Exportable=FALSE

SuppressDefaults=FALSE

ProviderName="Microsoft Base Smart Card Crypto Provider"
ProviderType=1

KeyAlgorithm=RSA
KeyLength=2048
KeySpec=AT_KEYEXCHANGE
KeyUsage=CERT_DIGITAL_SIGNATURE_KEY_USAGE|CERT_NON_REPUDIATION_KEY_USAGE|CERT_KEY_ENCIPHERMENT_KEY_USAGE|CERT_DATA_ENCIPHERMENT_KEY_USAGE|CERT_KEY_AGREEMENT_KEY_USAGE
KeyUsageProperty=NCRYPT_ALLOW_ALL_USAGES

HashAlgorithm=SHA512

SMIME=TRUE

[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2        ; Client Authentication
;OID=1.3.6.1.4.1.311.20.2.2    ; Smart Card Logon
OID=1.3.6.1.4.1.311.80.1    ; Document Encryption
OID=1.3.6.1.4.1.311.10.3.12    ; Document Signing
OID=1.3.6.1.5.5.7.3.4        ; Secure Email
OID=1.3.6.1.5.5.7.3.7        ; IP Security User
OID=1.3.6.1.4.1.311.10.3.4    ; Encrypting File System
OID=1.3.6.1.4.1.311.67.1.1    ; BitLocker Drive Encryption


[Extensions]
2.5.29.17 = "{text}"
_continue_ = "upn=ordinary.u@adsuffix&"
_continue_ = "EMail=ordinary.user@domainname.online&"

Обратите внимание на следующие параметры, в этом файле определенные:
1. ProviderName="Microsoft Base Smart Card Crypto Provider"  // желательно указать "конкретный" CSP, список которых получить можно командой ">certutil -csplist"
2. "upn=..." // Это значение будет указано в SAN. Оно должно совпадать с UPN ваших пользователей AD, быть с правильным uPNSuffix

Возможно я наивно упускаю какие-то тонкие моменты, но в принципиальной схеме проблемы не вижу:

• локальный пользователь Иванов создает вне домена настраиваемый запрос, с использованием необходимых oid'ов и т.д.

• Домен админ на основе запроса выпускает на доверенном доменном УЦ сертификат который

- ассоциирует с УЗ Иванова в AD (https://www.sysadmins.lv/blog-ru/autent … ertyj.aspx)

- возвращает сертификат локальному пользователю

• локальный пользователь связывает полученный сертификат с ключевой парой на токене, все счастливы

Я подозреваю, что все несколько сложнее.
Во-первых, в домене сертификаты выписываются по шаблону. Шаблон этот каким-то образом нужно экспортировать и передать пользователю.
Во-вторых, нужно сгенерировать ключи и создать CSR по нужному шаблону.
Потому уже передать CSR, выпустить сертификат и отправить его обратно пользователю.
Впрочем это мое предположение. Наверное можно попробовать для начала сгенерировать ключи и CSR через что-то вроде certreq

• локальный пользователь Иванов создает вне домена настраиваемый запрос, с использованием необходимых oid'ов и т.д.

• Домен админ на основе запроса выпускает на доверенном доменном УЦ сертификат который

- ассоциирует с УЗ Иванова в AD (https://www.sysadmins.lv/blog-ru/autent … ertyj.aspx)

- возвращает сертификат локальному пользователю

• локальный пользователь связывает полученный сертификат с ключевой парой на токене, все счастливы

Пользователь локальный, политики не действуют.
Назначение сертификата мне кажется в данном вопросе вторично?
В моем понимании, после того, как выпущенный в УЦ сертификат пользователь свяжет со своей ключевой парой, де-факто у него на  руках будет "боевой" ключ, который можно использовать для авторизации внутри домена, подписывания/расшифровки почты и т.д.

Для того, чтобы сертификат можно было использовать для аутентификации внутри домена, он должен быть выпущен не на локального пользователя, а на доменный аккаунт. Собственно и вопрос был относительно назначения сертификата поэтому. Одно дело - почту подписывать, например, а совсем другое - в домен аутентифицироваться.

Данная схема у нас реализована и исправно работает.
Её условно можно описать как взаимодействие в домене от админа к пользователю.
Требуется же ровно обратное - пользователь, находясь за пределами домена/организации на своем ключевом носителе генерирует  ключевую пару, отправляя запрос админу,  УЦ только подписывает сертификат, возвращая его заказчику.

Получается, что грубо говоря нам нужен "Генератор запросов Рутокен", но не на ГОСТе, а на RSA.

Пользователь при этом доменный или локальный? На машине доменные политики действуют? Назаначение сертификата какое предполагается (что потом пользователь с ним будет делать)?

Получается, что грубо говоря нам нужен "Генератор запросов Рутокен", но не на ГОСТе, а на RSA.

Добрый день.
1) Правильно ли понимать, что утилита "Генератор запросов сертификатов" работает с использованием только ГОСТовых алгоритмов шифрования?
2) Возможно ли с использованием продуктов Рутокен вообще и данной утилиты в частности, создавать запрос и ключевую пару с использованием алгоритма RSA?

Поясню задачу - есть стандартный УЦ на базе Microsoft Server 12, в нем стандартные же поставщики криптографии + Aktiv Soft (Рутокен). Есть токены  ЭЦП PKI. На данных ключах необходимо генерировать ключевую пару и запрос, который будет отправляться в УЦ на выпуск сертификата.
Подскажите пожалуйста - есть ли штатные средства или известные best practice с OpenSSL к примеру, для реализации данной задачи?

Здравствуйте! Для данной задачи можно, например, использовать web enrollment MS CA или оснастку "Сертификаты"  в MMC консоли. OpenSSL для таких целей использовать не нужно. Например, см. https://habr.com/ru/company/aktiv-company/blog/327232/

Поясню задачу - есть стандартный УЦ на базе Microsoft Server 12, в нем стандартные же поставщики криптографии + Aktiv Soft (Рутокен). Есть токены  ЭЦП PKI. На данных ключах необходимо генерировать ключевую пару и запрос, который будет отправляться в УЦ на выпуск сертификата.
Подскажите пожалуйста - есть ли штатные средства или известные best practice с OpenSSL к примеру, для реализации данной задачи?