| ||||
| ||||
| Не работает CryptSignAndEncodeCertificate под win2000. Ошибка 80090008h (NTE_BAD_ALGID). Параметры провайдера следующие: CSP=Crypto-Pro Cryptographic Service Provider Type=2 ExchAlg=43550 HashAlg=32798 SymmAlg=26142 ExchLen=1024 Секретный ключ: dwKeySpec=AT_KEYEXCHANGE win2000 - "голая" (установлен только SP3 и 2 рекомендованных в документации патча). С другим криптопровайдером (MS), либо с крипто-про, но на других ОС (98, ME, XP) серитфикаты создаются нормально. Указанные алгоритмы с помощью CryptGetProvParam(hProv, PP_ENUMALGS_EX, ...) программа находит. CertAlgIdToOID определяет CertInfo.SignatureAlgorithm.pszObjId=’1.2.643.2.2.9’ В чем может быть дело? | ||||
| Ответы: | ||||
| ||||
| Если кому интересно решение: в документации на CryptSignAndEncodeCertificate говорится, что параметр pSignatureAlgorithm может принимать одно из 3 значений: szOID_RSA_MD5RSA szOID_RSA_SHA1RSA szOID_X957_SHA1DSA Я же, как написано выше, использовал ГОСТовский: CertAlgIdToOID(FHashAlg), где FHashAlg=32798. И под XP это работало! (создавались сертификаты с алгоритмом подписи ГОСТ Р 34.11-94). ОС Win2000 server отказалась это делать. Я стал перебирать алгоритмы указанные в документации и оказалось, что провайдер Крипто про не знает szOID_RSA_MD5RSA, но создает сертификаты с алгоритмом подписи szOID_RSA_SHA1RSA, и это также заработало под win2000. На этом часть проблемы решена. А теперь новая проблема. Указанное поведение криптопровайдера (а может, операционной системы) заставляет при генерации сертификатов использовать несертифицированный алгоритм (подписывается хеш SHA1). Будет ли такой сертификат соответствовать закону об ЭЦП и не будет ли при "разборках" владелец такого сертификата послан куда подальше? Как быть? | ||||
| ||||
| SHA 1 поддерживается в качества алгоритма хэша по нескольким причинам, но при это подпись (это же не ГОСТ) Вы проверить не сможете. PS. Вроде как SP4 вышел уже. | ||||
Ivan Ravin