如何在 LDAP 中使用 userPKCS12 存储密钥库? [英] How to store Keystore using userPKCS12 in LDAP?

问题描述

我有一个 java 密钥库，我想使用 userPKCS12 属性将它存储在 LDAP 中.我已经将 JKS 密钥库转移到 PKCS12

keytool -importkeystore -srckeystore/opt/tomcat/conf/.keystore -destkeystore/tmp/tomcat.p12 -deststoretype PKCS12

如何继续最终将此密钥库的条目放入我的 LDIF 文件?

dn:cn=$name,$cn对象类:顶部对象类:inetorgPerson描述:$名称cn: $名称序号:$名称userPKCS12;二进制:: MIIQoAIBAzCCEFoGCSqGSIb3DQEHAaCCEEsEghBHMIIQQzCCCfAGCSqGSIb3DQEHAaCCCeEEggndMIIJ2TCCCdUGCyqGSIb3DQEMCgECoIIJgjCCCX4wKAYKKoZIhvcNAQwBAzAaBBQJgfNb/kt83JjEL34s/vE5pFjL0wICBAAEgglQ0DQ23QhylRz4uvMrlleD94JSA6hdpLjsee3zxqxsPXgyz1CtsY159vw4F6rSHeSDaILve8g2w/nA0KPHV/QbsbAU6/g8tvqBGbbLJFbe20m9ZhAOeohPdLzT54SViJ8b3VvZf5rWCidUaYQu7yNqjkXAbuezRxf3TMEuR9BNQV+DWLjvNmiMGN3b1rQ0jFZHKk1VJnb6OUn63UUTdRun7OUdi9zR4WM7yKy0VNmC3xaI630PABibIACMdGaQGprQM6HrchkxP2M3D5jm8UwCkEYazd7eKyKiAEEMnK5o3nKYWbd+NmELssendiEoi3ztrLTZnEdIwUc9wA3/yJgcptUjzbh/2NwKdyO21Snj9iGWyw90KqI3hfL1HqiYKjF+sZ9nudxFLwbmYi0Y......

给出这个错误:

ldapadd -h 10.1.0.99 -D cn=Directory Manager -w - -f action.ldif输入绑定密码:添加新条目 cn=abcd,dc=Example,dc=comldap_add:未定义的属性类型ldap_add:附加信息:无法添加条目 cn=abcd,dc=Example,dc=com，因为不支持 userPKCS12 属性的 BER 编码

首选 bash 脚本解决方案.

感谢和问候，

丹尼尔

解决方案

LDIF 中的二进制数据

LDIF 文件中的二进制数据只是经过 Base64 编码(请参阅 RFC 2849):

userPKCS12:: MIIJtgIBAzCCCXAGCSqGSIb3DQEHAaCCCWEEggldMIIJWTCCBW4GCSqGSIb3DQEHACCBV8EggVbMIIFVzCCBVMGCyqGSIb3DQEMCgECoIIE+jCCBPYwKAYKKoZIhvcNAQwBAzAaBBT3WG...

RFC 2849 明确声明不需要换行:

<块引用>

10. 当 attrval-spec、distinguishedName 或 rdn 是 base64-编码，[5]中指定的编码规则与以下例外: a) base64 输出的要求流必须表示为不超过 76 行字符被删除.LDIF 文件中的行只能折叠根据上面注释 2 中描述的折叠规则.

话虽如此，我从未见过没有折叠长行的 LDIF 文件.因此，出于兼容性考虑，无论如何最好在 76 个字符后添加换行符.

LDIF 中折线的规则是:

<块引用>

1. LDIF 文件中的任何非空行，包括注释行可以通过插入行分隔符 (SEP) 和空格来折叠.折叠不得发生在该行的第一个字符之前.换句话说，将一条线折叠成两条线，第一条这是空的，是不允许的.任何以 a 开头的行必须将单个空格视为前一个空格的延续(非空)行.连接折叠线时，正好一个空格每个连续行开头的字符必须是丢弃.实现不应该在中间折叠线多字节 UTF-8 字符.

对外部文件的引用

二进制数据不一定要作为 Base64 字符串包含在 LDIF 文件中.相反，可以使用对外部文件的引用.RFC 2849 的示例:

jpegphoto:<文件:///usr/local/directory/photos/fiona.jpg

传输选项二进制"

二元选项;binary"在 RFC 4522 中指定，它会影响 LDAP 客户端和服务器之间的数据传输(不是 LDAP 服务器上的存储).设置后，根据基本编码规则 (BER) 对属性进行编码.

是否二进制"userPKCS12"是必需的.取决于 LDAP 服务器.例如，使用 OpenLDAP二进制".不起作用，因为userPKCS12"的语法是二进制的(不是 PKCS#12 的特殊语法).

二进制数据到 Base64 的转换

有很多方法可以将 PKCS#12 文件转换为 Base64，如果您必须以编程方式或使用命令行工具执行此操作，则无需编写.一些选项是:

• OpenSSL:openssl enc -e -base64 -in tomcat.p12 -out tomcat.b64
• 带有 Bouncy Castle 的 Java:Base64.编码()
• 一些 LDAP 服务器(如 Sun Directory Server、389 或 RedHat Directory Server)包含一个名为ldif"的命令行工具.这正是你想要的: ldif -b "userPKCS12";<tomcat.p12>>p12.ldif

I got a java keystore which I want to store in LDAP using userPKCS12 attribute. I already transfered the JKS keystore to PKCS12

keytool -importkeystore -srckeystore /opt/tomcat/conf/.keystore -destkeystore /tmp/tomcat.p12 -deststoretype PKCS12

How do I proceed to finally get the entries of this keystore into my LDIF-file?

dn: cn=$name,$cn
objectClass: top
objectClass: inetorgPerson
description: $name
cn: $name
sn: $name
userPKCS12;binary:: MIIQoAIBAzCCEFoGCSqGSIb3DQEHAaCCEEsEghBHMIIQQzCCCfAGCSqGSIb3DQEH
 AaCCCeEEggndMIIJ2TCCCdUGCyqGSIb3DQEMCgECoIIJgjCCCX4wKAYKKoZIhvcN
 AQwBAzAaBBQJgfNb/kt83JjEL34s/vE5pFjL0wICBAAEgglQ0DQ23QhylRz4uvMr
 lleD94JSA6hdpLjsee3zxqxsPXgyz1CtsY159vw4F6rSHeSDaILve8g2w/nA0KPH
 V/QbsbAU6/g8tvqBGbbLJFbe20m9ZhAOeohPdLzT54SViJ8b3VvZf5rWCidUaYQu
 7yNqjkXAbuezRxf3TMEuR9BNQV+DWLjvNmiMGN3b1rQ0jFZHKk1VJnb6OUn63UUT
 dRun7OUdi9zR4WM7yKy0VNmC3xaI630PABibIACMdGaQGprQM6HrchkxP2M3D5jm
 8UwCkEYazd7eKyKiAEEMnK5o3nKYWbd+NmELssendiEoi3ztrLTZnEdIwUc9wA3/
 yJgcptUjzbh/2NwKdyO21Snj9iGWyw90KqI3hfL1HqiYKjF+sZ9nudxFLwbmYi0Y
.....

Gives this error:

ldapadd -h 10.1.0.99 -D cn=Directory Manager -w - -f action.ldif
Enter bind password: 
adding new entry cn=abcd,dc=Example,dc=com
ldap_add: Undefined attribute type
ldap_add: additional info: Entry cn=abcd,dc=Example,dc=com can not be added because BER encoding of userPKCS12 attribute is not supported

Solutions for bash scripts are preferred.

Thanks and regards,

Daniel

解决方案

Binary Data in LDIF

Binary data in LDIF files is simply Base64 encoded (see RFC 2849):

userPKCS12:: MIIJtgIBAzCCCXAGCSqGSIb3DQEHAaCCCWEEggldMIIJWTCCBW4GCSqGSIb3DQEHA
 CCBV8EggVbMIIFVzCCBVMGCyqGSIb3DQEMCgECoIIE+jCCBPYwKAYKKoZIhvcNAQwBAzAaBBT3WG
 ...

RFC 2849 explicitly states that line breaks are not required:

10. When an attrval-spec, distinguishedName, or rdn is base64- encoded, the encoding rules specified in [5] are used with the following exceptions: a) The requirement that base64 output streams must be represented as lines of no more than 76 characters is removed. Lines in LDIF files may only be folded according to the folding rules described in note 2, above.

That being said, I have never seen an LDIF file where long lines were not folded. So, it might be a good idea to add line breaks after 76 characters anyway, just for compatibility reasons.

Rules for folding lines in LDIF are:

2. Any non-empty line, including comment lines, in an LDIF file MAY be folded by inserting a line separator (SEP) and a SPACE. Folding MUST NOT occur before the first character of the line. In other words, folding a line into two lines, the first of which is empty, is not permitted. Any line that begins with a single space MUST be treated as a continuation of the previous (non-empty) line. When joining folded lines, exactly one space character at the beginning of each continued line must be discarded. Implementations SHOULD NOT fold lines in the middle of a multi-byte UTF-8 character.

References to External Files

Binary data must not necessarily be included in the LDIF file as a Base64 string. Instead a reference to an external file can be used. Example from RFC 2849:

jpegphoto:< file:///usr/local/directory/photos/fiona.jpg

Transfer Option ";binary"

The binary option ";binary" is specified in RFC 4522, it affects the transfer of data between LDAP client and server (not the storage on the LDAP server). When it is set, the attribute is encoded according to the Basic Encoding Rules (BER).

Whether ";binary" is required for "userPKCS12" depends on the LDAP server. For example with OpenLDAP ";binary" does not work, because the syntax of "userPKCS12" is binary (and not a special syntax for PKCS#12).

Conversion of Binary Data to Base64

There are many ways to convert the PKCS#12 file to Base64 and you did not write if you have to do this programmatically or with command line tools. Some options are:

• OpenSSL: openssl enc -e -base64 -in tomcat.p12 -out tomcat.b64
• Java with Bouncy Castle: Base64.encode()
• Some LDAP servers like Sun Directory Server, 389 or RedHat Directory Server include a command line tool named "ldif" that does exactly what you want: ldif -b "userPKCS12" < tomcat.p12 >> p12.ldif

这篇关于如何在 LDAP 中使用 userPKCS12 存储密钥库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！