以编程方式创建 CSR
我正在尝试以编程方式创建 CSR。我读过有关 ASN.1、RFC 2986、X.509 的内容。
我还手动解析了几个使用 OpenSSL 创建的 DER 编码的 CSR 文件。
除了以下几点之外，一切看起来都很清楚：
公钥部分包含 BIT STRING 内容之前（以及
03 81 之后）的下一个字节8D 00 30 81 89 02 81 81>）。这是什么？我注意到所有用 DER 编码的 CSR 文件都包含它们。我在 RFC 中没有找到任何有关它们的信息。签名部分包含签名内容之前但
03 81之后的下一个不清楚的字节。据我了解，这部分包含有关 BIT STRING 中最后一个八位字节的信息（最后一个字节中实际应该占用多少字节）。但我不明白如何解码这些字节。例如，签名可能如下所示：03 81 81 00 64 12 ... 24 B1 28
其中03h是 BIT STRING 格式，81h位串长度，64 12 ... 24 B1 28是签名（但它长度为 80h)。我不明白81 00部分。
提前致谢。
I am trying to create a CSR programmatically. I've read about ASN.1, RFC 2986, X.509.
I have also parsed several DER-encoded CSR files manually which were created using OpenSSL.
Everything looks clear except for a couple of things:
Public key part contains next bytes
8D 00 30 81 89 02 81 81before the BIT STRING content (and after03 81). What is this? I noticed that all CSR files encoded with DER contain them. I didn't find anything about them in the RFC.Signature part contains next unclear bytes before the signature content but after
03 81. As I understand this part contains information about the last octet in BIT STRING (how much bites in last byte actually should be taken). But I don't understand how to decode these bytes. For example the signature could look like the following:03 81 81 00 64 12 ... 24 B1 28
where03his a BIT STRING format,81hlength of the bit string,64 12 ... 24 B1 28is a signature (but it has length 80h). I don't understand the part81 00.
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
SubjectPublicKeyInfo 中的位字符串取决于您的公钥算法。内容再次进行 DER 编码，请参阅 RFC 3370 了解可能性。
如果你的签名看起来像这样
03 81 81 00 64 12 ... 24 B1 28
则应按如下方式解释。 DER 是一个 TLV（标签- 长度 - 值）编码。因此，第一个字节（用他们的说法是八位字节）代表标签 - 03 代表位字符串，正如您所注意到的那样。
第二个字节决定长度：
81将第 8 位设置为 1，因此其余位表示确定总长度的字节数。在您的情况下，它只是1字节。所以下一个字节是你的长度 - 81 等于签名长度 129 字节。所以接下来的 129 个字节代表你的值，从 00 开始。The BIT STRING in the SubjectPublicKeyInfo depends on your public key algorithm. The contents are again DER-encoded, see RFC 3370 for possibilities.
If your signature looks like
03 81 81 00 64 12 ... 24 B1 28
this is to be interpreted as follows. DER is a TLV (Tag - Length - Value) encoding. So the first byte (octet in their parlance) represents the tag - 03 for BIT STRING as you noticed correctly.
The second byte determines the length:
81has bit 8 set to one, so the remaining bits indicate the number of bytes that determine the overall length. In your case it's simply1byte. So the next byte is your lenght - 81 being equal to signature length of 129 bytes. So the following 129 bytes represent your value, starting with the 00.当您说“以编程方式”时，您到底是什么意思？在代码中？如果是这样，您使用什么语言？ BouncyCastle JCE 提供程序包含用于生成 PKCS#10 请求的类（前提是您使用的是 Java）。您需要做的就是指定必要的组件（DN、公钥等）。我相信，还有一个 .Net 实现，它可能更适合 Microsoft 环境。
When you say 'programmatically', what exactly do you mean? In code? If so, what language are you using? The BouncyCastle JCE provider contains classes for generating a PKCS#10 request, provided you're using Java. All you need to do is specify the necessary components (DN, public key, etc.) There is also a .Net implementation, I believe, which may be more suitable for Microsoft environments.