| ||||
| ||||
Я повторяю вопросы, на которые так и не получил ответа 1. Поля в строке Subject каждый УЦ обрабатывает как хочет и пропускает то что хочет или есть какой-нибудь минимум полей, которые любой УЦ обязательно должен обработать? 2. Расширения сертификата каждый УЦ может обрабатывать по своему или есть какой-либо минимум, который люыбой УЦ оюязательно должен обработать? 3. Как собственно добавить эти расширения в сертификат. Мой запрос с расширением сгенерировался программно без ошибок. Ваш тестовый УЦ без ошибок этот запрос обработал, но самого расширения в итоговом сертификате нет. Как это понимать? | ||||
Ответы: | ||||
| ||||
1. Состав атрибутов имени субъекта определяется регламентом (политикой) УЦ. 2. Это зависит от проектного решения при создании информационной системы (УЦ). 3. Присланный Вами запрос показал, что он сгенерен с ошибками. Посмотрите пример "правильного" запроса: MIICRjCCAfMCAQAwgaAxHDAaBgkqhkiG9w0BCQEWDUdUU1QxQHRlc3QucnUxCzAJBgNVBAYTAlJV MRUwEwYDVQQIHgwAUgB1AHMAcwBpAGExFTATBgNVBAceDABNAG8AcwBjAG8AdzEPMA0GA1UECh4G AEIAUwBTMR8wHQYDVQQLHhYARABlAHYAZQBsAG8AcABtAGUAbgB0MRMwEQYDVQQDHgoARwBUAFMA VAAxMIGlMBwGBiqFAwICFDASBgcqhQMCAiACBgcqhQMCAh4BA4GEAASBgCLlDSXRqNRnJq/9OdVp V7wd3QQxSYqxAPGKQwKDoeDwA/pQdhM+ynjGO5p7mCJma/0pDT4+3CnE0/anzzxGDWNo8zUczJzp Ps4WP/AZMyAgWK/aPifN1PI/kehtfsjWAIWd/piM83yG6YI8221esAbU4KCTsSw+C2R9EpZSHIUK oIGiMC4GCisGAQQBgjcCAQ4xIDAeMBwGA1UdJQQVMBMGCCsGAQUFBwMCBgcqhQMCAiICMHAGCSqG SIb3DQEJDjFjMGEwFQYDVR0RBA4wDKAKBgNVBAygAxMBMDBIBgNVHQIEQTA/BA1HVFNUMUB0ZXN0 LnJ1AwIFIDAqgBMyMDAyMTIxNjE1Mjc1NS4xOTJagRMyMDAzMTIxNjE1Mjc1NS4xOTJaMAoGBiqF AwICBAUAA0EAhQ9O3lFf0W2BKIqaEnEMiyzWaWgCj9Cptf9MnBjdVKF9Ajs2nh6HzXKDkAeCL2BU S598kou+80wikPtJ0DnaNQ== Наш тестовый УЦ - это стандартный Microsoft CA. А его модуль политики просто игнорирует ошибки в запросе, перенося в сертификат значения атрибутов без ошибок. | ||||
| ||||
Замечательно. В вашем примере есть поле альтернативного имени суюъекта. Я для добавления такого использую следующий код: CERT_OTHER_NAME MyName; MyName.pszObjId=szOID_SUBJECT_ALT_NAME; MyName.Value.cbData=strlen("TestOtherName"); MyName.Value.pbData="TestOtherName"; CERT_ALT_NAME_ENTRY MyAttr; MyAttr.dwAltNameChoice=CERT_ALT_NAME_OTHER_NAME; MyAttr.pOtherName=&MyName; CERT_ALT_NAME_INFO MyAttrArray={1,&MyAttr}; CERT_EXTENSION MyExt; MyExt.pszObjId=szOID_SUBJECT_ALT_NAME; MyExt.fCritical=FALSE; CERT_EXTENSIONS MyExts; MyExts.cExtension=1; MyExts.rgExtension=&MyExt; CRYPT_ATTR_BLOB RoleBlob={0,NULL}; // также вместо X509_ALTERNATE_NAME использовалось szOID_SUBJECT_ALT_NAME с тем же результатом CryptEncodeObject(MY_ENCODING_TYPE,X509_ALTERNATE_NAME,&MyAttrArray,NULL,&MyExt.Value.cbData); MyExt.Value.pbData = (LPBYTE)malloc(MyExt.Value.cbData); CryptEncodeObject(MY_ENCODING_TYPE,X509_ALTERNATE_NAME,&MyAttrArray,MyExt.Value.pbData,&MyExt.Value.cbData); CryptEncodeObject(MY_ENCODING_TYPE,X509_EXTENSIONS,&MyExts,NULL,&RoleBlob.cbData); RoleBlob.pbData = (LPBYTE)malloc(RoleBlob.cbData); CryptEncodeObject(MY_ENCODING_TYPE,X509_EXTENSIONS,&MyExts,RoleBlob.pbData,&RoleBlob.cbData); CRYPT_ATTRIBUTE rgAttrib={szOID_CERT_EXTENSIONS, 1, &RoleBlob}; CertReqInfo.cAttribute = 1; CertReqInfo.rgAttribute = &rgAttrib; и далее как в примере. Что здесь неправильно? | ||||
| ||||
Почему не получается. Потому что запрос на сертификат описан в PKCS#10. Он состоит из: CertificationRequest ::= SEQUENCE { certificationRequestInfo CertificationRequestInfo, signatureAlgorithm SignatureAlgorithmIdentifier, signature Signature } Соответственно CertificationRequestInfo ::= SEQUENCE { version Version, subject Name, subjectPublicKeyInfo SubjectPublicKeyInfo, attributes [0] IMPLICIT Attributes } где Attributes ::= SET OF Attribute * attributes is a set of attributes providing additional information about the subject of the certificate. Some attribute types that might be useful here are defined in PKCS #9. An example is the challenge-password attribute, which specifies a password by which the entity may request that the certificate revocation. Another example is the extended-certificate-attributes attribute, which specifies attributes for a PKCS #6 extended certificate. В запросе не может быть дополнений Х.509, если только не использовать атрибут extensionRequest, определенный рекомендациями PKCS #9 v2.0: Selected Object Classes and Attribute Types (February 25, 2000). The extensionRequest attribute type may be used to carry information about certificate extensions the requester wishes to be included in a certificate. extensionRequest ATTRIBUTE ::= { WITH SYNTAX ExtensionRequest SINGLE VALUE TRUE ID pkcs-9-at-extensionRequest } ExtensionRequest ::= Extensions The Extensions type is imported from [10] (это Х.509). Если вы хотите, чтобы центр пропускал дополнения Х.509, вам сначала нужно создать атрибут 1.2.840.113549.1.9.14 а в него уже положить дополнение Х.509. | ||||
| ||||
А можно пример кода? И почему тогда назначение ключа добавляется в сертификат при помощи szOID_CERT_EXTENSIONS, а не при помощи указанного вами идентифкатора. Ведь это тоже дополнительное расширение и оно вроде бы является расширением X509 | ||||
| ||||
Так как насчет примера? | ||||
| ||||
Если у вас установлен Platform SDK и если вы посмотрите в файл wincrypt.h, то увидете определение #define szOID_CERT_EXTENSIONS "1.3.6.1.4.1.311.2.1.14" | ||||
| ||||
> Если у вас установлен Platform SDK и если вы посмотрите в файл wincrypt.h, то увидете определение > #define szOID_CERT_EXTENSIONS "1.3.6.1.4.1.311.2.1.14" И что это значит? | ||||
| ||||
А значит это лишь то, что в ответ на ваш вопрос: >>>>> почему тогда назначение ключа добавляется в сертификат при помощи szOID_CERT_EXTENSIONS, а не при помощи указанного вами идентифкатора. Ведь это тоже дополнительное расширение и оно вроде бы является расширением X509 я вам всего лишь написал, что szOID_CERT_EXTENSIONS и 1.3.6.1.4.1.311.2.1.14 это одно и то же. | ||||