如何在LDAP中使用userPKCS12存储密钥库?

Binary data in LDIF files is simply Base64 encoded (see RFC 2849):userPKCS12:: MIIJtgIBAzCCCXAGCSqGSIb3DQEHAaCCCWEEggldMIIJWTCCBW4GCSqGSIb3DQEHA CCBV8EggVbMIIFVzCCBVMGCyqGSIb3DQEMCgECoIIE+jCCBPYwKAYKKoZIhvcNAQwBAzAaBBT3WG ... RFC 2849明确指出不需要换行符:RFC 2849 explicitly states that line breaks are not required: 10)当attrval-spec，distinguishedName或rdn为base64- 编码后，[5]中指定的编码规则与 以下例外:a)base64输出的要求 流必须以不超过76行表示 字符已删除. LDIF文件中的行只能折叠 根据上面注释2中所述的折叠规则. 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.话虽这么说，但我从未见过没有折叠长行的LDIF文件.因此，出于兼容性考虑，最好在76个字符后添加换行符.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. LDIF中折线的规则是:Rules for folding lines in LDIF are: 2)LDIF文件中的任何非空行，包括注释行 可以通过插入行分隔符(SEP)和空格来折叠. 折叠不得出现在该行的第一个字符之前. 换句话说，将一条线折叠成两行，第一个是 不允许为空.以a开头的任何行 单个空间必须被视为前一个空间的延续 (非空)行.连接折线时，只有一个空格 每条连续行开头的字符必须为 丢弃.实现不应该在中间折叠线 多字节UTF-8字符. 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. 对外部文件的引用二进制数据不一定必须作为Base64字符串包含在LDIF文件中.而是可以使用对外部文件的引用.来自 RFC 2849 的示例: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 转移选项;二进制"二进制选项; binary"在 RFC 4522 中指定，它会影响传输LDAP客户端和服务器之间的数据(不是LDAP服务器上的存储).设置该属性后，将根据基本编码规则(BER)对属性进行编码.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)."userPKCS12"是否需要; binary"取决于LDAP服务器.例如，对于OpenLDAP，; binary"不起作用，因为"userPKCS12"的语法是二进制的(而不是PKCS#12的特殊语法).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). 将二进制数据转换为Base64有很多方法可以将PKCS#12文件转换为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带有Bouncy Castle的Java: Base64. encode()某些LDAP服务器(例如Sun Directory Server，389或RedHat Directory Server)包括一个名为" ldif "的命令行工具，它可以完全满足您的需求:ldif -b "userPKCS12" < tomcat.p12 >> p12.ldifOpenSSL: openssl enc -e -base64 -in tomcat.p12 -out tomcat.b64Java 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存储密钥库?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 1403页，肝出来的..