не могу добавить сертификат КриптоПро в usercertificate (binary)

[im]

Сертификат УЦ КриптоПро в кодировке DER не добавляется в стандартную схему сервера openldap-servers-2.4.39-3.el7.x86_64 на Centos7

Посоветуйте пожалуйста куда копать?

Добавляю при помощи Apache Dir Studio (самый распоследний Version: 2.0.0.v20130628 at 2015.07.30 )
При загрузке файла (кнопка Load Cert) отображает все поля сертификата но когда пытается сохранить в базу LDAP по кнопке ОК возвращает ошибку:

#!ERROR [LDAP: error code 21 - userCertificate;binary: value #0 normalization failed]

сам сертификат отличается от других загружаемых нормально сертификатов, вроде бы только наличием расширения x509 компании КриптоПро -   а именно Идентификатор ключа Центра сертификатов (2.5.29.35)

Оно (расширение) включается и выключается в УЦ КриптоПро в:

Модль политики ЦС - Прочие настройки
галки на
 "Запретить поля "Издатель" и "Серийный номер" в расширении 2.5.29.35", то информация о поставщике будет добавляться.
Поставите галки - будет добавлять только идентификатор

Но на это я влиять не могу.

Больше отличий от нормально загружаемых сертификатов я пока не нашел.

Команда
openssl x509 -in ./shit_cert.cer -inform DER -text
ошибок не возвращает


Спасибо!



p.s.


Из командной строки картина аналогичная
файл сертификата в кодировке DER


cat ./cer.ldif
   
dn: cn=anisimov,o=000,dc=aaa,dc=bbb
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///root/wrong_certs/shit_cert.cer



ldapmodify -x -W -D "cn=000,dc=aaa,dc=bbb" -f ./cer.ldif
Enter LDAP Password:
modifying entry "cn=anisimov,o=000,dc=aaa,dc=bbb"
ldap_modify: Invalid syntax (21)
        additional info: userCertificate;binary: value #0 normalization failed


если добавить -v
то


[root@centos7 wrong_certs]# ldapmodify -v -x -W -D "cn=Manager,dc=aaa,dc=bbb" -f ./cer.ldif
ldap_initialize( <DEFAULT> )
Enter LDAP Password:
add userCertificate;binary:
        NOT ASCII (1831 bytes)
modifying entry "cn=anisimov,o=000,dc=aaa,dc=bbb"
ldap_modify: Invalid syntax (21)
        additional info: userCertificate;binary: value #0 normalization failed




LogLevel -1 на slapd.conf говорит на проблему следующее



авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=13 MOD dn="cn=anisimov,o=000,dc=aaa,dc=bbb"
авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=13 MOD attr=userCertificate;binary
авг 03 14:33:36 centos7.000.ru slapd[13909]: <= str2entry NULL (ssyn_normalize 21)
авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=13 RESULT tag=103 err=21 text=userCertificate;binary: value #0 normalization failed
авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=14 SRCH base="cn=anisimov,o=000,dc=aaa,dc=bbb" scope=0 deref=3 filter="(objectClass=*)"
авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=14 SRCH attr=*
авг 03 14:33:36 centos7.000.ru slapd[13909]: conn=1000 op=14 SEARCH RESULT tag=101 err=0 nentries=1 text=

[znaesh]

Парсер сертификатов http://lapo.it/asn1js ничего интересного не говорит?

[im]

Да пробовал. На ASN1 не жалуется и ничего интересного не видно. Ни варнингов ни depricated сообщений нет.
Куда еще покопать?

[im]

Очень странно но все заработало без ошибок нормализации на ApacheDirectory Server
apacheds-2.0.0-M20-64bit.bin

В него сертификат прекрасно грузится.

[egor]

Здравствуйте! Извините, что не сразу ответил -- был в отпуске, не до того было =). С нормализацией сертификатов всегда выходит негладко =) .

Очень странно но все заработало без ошибок нормализации на ApacheDirectory Server
apacheds-2.0.0-M20-64bit.bin

В него сертификат прекрасно грузится.

Видимо, синтаксисы атрибута userCertificate в OpenLDAP и ApacheDS отличаются. В OpenLDAP всё всегда делают по стандарту, разработчики других серверов обычно смягчают чересчур строгие требования для упрощения работы пользователей. В принципе, ничего страшного в этом нет, с точки зрения приложения, запрашивающего сертификат, синтаксис атрибута не имеет никакого значения =) . Если проблема всё ещё актуальна, можно заменить синтаксис в схеме данных  OpenLDAP на тот что используется в ApacheDS. Либо пришлите мне проблемный сертификат, постараюсь с ним поковыряться =) .

Егор

[im]

Егор огромное спасибо за помощь.
Подумаю некоторое время, что делать далее.
Отпишу сюда о результатах.

[im]

Отписываю.
Пока забили и используем OpenDJ
потому что он убедителен в http://fr.slideshare.net/ldapcon/benchmarks-on-ldap-directories

[egor]

Пока забили и используем OpenDJ
потому что он убедителен в http://fr.slideshare.net/ldapcon/benchmarks-on-ldap-directories

Да, действительно, ApacheDS выглядит на сравнениях бледно =( . Ну да ладно, OpenLDAP с mdb всё же быстрее OpenDJ, но, думаю, в повседневном использовании вряд ли потебуется ежесекундно добавлять/извлекать десятки тысяч записей (хотя как сказать =) ), так что это не существенно.

Егор

[Kom6aT]

Добрый день.
У меня аналогичная проблема - не получается записать сертификат в userCertificate на OpenLDAP.

Записываю через ldapmodify.

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate
userCertificate:< file:///root/3.cer

то получаю в ответ:

ldap_modify: Undefined attribute type (17)
        additional info: userCertificate: requires ;binary transfer

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate
userCertificate;binary:< file:///root/3.cer

то получаю в ответ:

wrong attributeType at line 4, entry "cn=07781012064,ou=users,dc=iis,dc=loc"

Если делать так:

dn: cn=07781012064,ou=users,dc=iis,dc=loc
changetype: modify
add: userCertificate;binary
userCertificate;binary:< file:///root/3.cer

то получаю в ответ:

ldap_modify: Invalid syntax (21)
        additional info: userCertificate;binary: value #0 normalization failed


Подскажите, пожалуйста, в чём может быть причина? Что я делаю не так?

[egor]

Здравствуйте! Уже сто лет не касался сертификатов в каталогах, но с ними всегда проблемы =( . Начиная от банальной кодировки сертификата в файле .cer (PEM/DER), не помню точно, в какой он должен быть при загрузке в каталог, но  файл легко переконвертировать туда-сюда с помощью команды openssl, что-то вроде:

Код: [Выделить]

openssl x509 -in cert.pem -out cert.der -outform DER
Реже бывает, что в файле находится не "чистый" сертификат, а обёрнутый в какой-нибудь контейнер. Тогда сертификат перед загрузкой в каталог нужно извлечь из этого контейнера.

Наконец, часто сертификаты, сгенерированные, например, CryptoPro, содержат поля, о которых не знает библиотека openssl (или другая), с которой скомпилирован OpenLDAP. Соответственно, такой сертификат не проходит валидацию на уровне криптобиблиотеки и не загружается =( .

Чтобы не заморачиваться с проверкой синтаксиса сертификатов, производители других каталогов подменяют синтаксис атрибута userCertificate на 1.3.6.1.4.1.1466.115.121.1.40 (Octet String) вместо 1.3.6.1.4.1.1466.115.121.1.8 (X.509 Certificate), обычно никаких проблем при этом не возникает. Во внутреннем каталоге вы можете сделать то же самое.

Егор