使用 secp384r1 椭圆曲线密钥和 sha384 哈希签名生成 csr答案

【问题标题】：generate csr with secp384r1elliptic curve key and sha384 hash signature使用 secp384r1 椭圆曲线密钥和 sha384 哈希签名生成 csr
【发布时间】：2013-05-24 22:57:59
【问题描述】：

我正在使用 openssl 命令创建一个具有椭圆曲线 secp384r1 和哈希签名算法 sha384 的 CSR：

openssl ecparam -out ec_client_key.pem -name secp384r1 -genkey

openssl req -new -key ec_client_key.pem -out ec_clientReq.pem

然后我使用以下命令以可读格式显示 CSR：

openssl req -in ec_clientReq.pem -noout -text

在 CSR 的签名部分我得到这个：

Signature Algorithm: ecdsa-with-SHA1
    30:64:02:30:06:a1:f2:5e:1b:34:18:b9:f3:7c:e9:52:c8:78:
    99:90:63:d2:1e:d2:f5:7a:25:f3:d6:4d:6d:90:d0:bf:25:45:
    15:ad:aa:17:34:ad:1a:b9:1e:67:2b:cf:d7:a6:9b:e5:02:30:
    31:fe:76:37:4b:11:3a:e7:2d:63:52:bb:18:2f:8e:43:a7:bb:
    65:74:38:a4:92:38:9d:eb:ec:22:8f:77:f3:e4:5f:47:2d:f8:
    2a:9b:e1:2c:ba:a7:b0:e6:c2:54:8d:0e

我应该怎么做才能获得签名算法“ecdsa-with-SHA384”而不是“ecdsa-with-SHA1”？我在这个过程中遗漏了什么吗？我尝试在第二个命令中使用 -sha384

openssl req -new -key ec_client_key.pem -out ec_clientReq.pem -sha384

但我在签名算法方面得到了相同的结果

Signature Algorithm: ecdsa-with-SHA1
    30:65:02:30:4e:b4:b6:5f:3a:fc:b7:28:e5:4b:f0:3d:9a:ea:
    4a:ba:ce:a4:f1:a6:e8:cd:15:19:23:a6:81:3f:24:01:d7:81:
    3c:9d:9a:4c:cd:4b:4a:12:6d:69:48:ec:7e:73:7d:73:02:31:
    00:d7:a5:63:9b:21:b2:95:ce:7f:13:3f:c5:1a:ac:99:01:ff:
    ba:9c:59:93:d5:ee:97:03:b5:9e:c1:7d:03:f8:72:90:65:b5:
    08:7c:79:ae:ea:4f:6e:b0:2b:55:1a:11:a5

另一个问题是关于签名的格式。在上面的例子中，一个是 102 字节长，第二个是 103 字节长。似乎第一个字节是一个标头，包括类型、长度，并且可能是一些其他的东西，比如填充。但我找不到确切的定义。有人可以对此有所了解吗？谢谢

【问题讨论】：

这个问题似乎属于 Stack Exchange 网络中的另一个站点，因为它与编程无关。也许Super User.

标签： openssl csr

【解决方案1】：

这次我再次尝试使用最后一个 openssl 版本 1.0.1e（而不是 0.9.8n）。

openssl ecparam -out ec_client_key.pem -name secp384r1 -gen

openssl req -config openssl.cnf -new -key ec_client_key.pem -out ec_clientReq.pem -sha384

openssl req -in ec_clientReq.pem -noout -text

现在我得到了预期的结果：

签名算法：ecdsa-with-SHA384

看起来0.9.8n版本不支持sha384。

来自 CHANGES 文件的这段摘录似乎证实了这一点：

1.0.0h 和 1.0.1 [2012 年 3 月 14 日] 之间的更改：... *) 添加 HMAC ECC 来自 RFC5289 的密码套件。包括 SHA384 PRF 支持。根据 RFC5289 的要求，这些密码套件不能用于早于 1.2 的 TLS 版本。 [史蒂夫汉森]

感谢 gtrig 的帮助。

【讨论】：

【解决方案2】：

当我使用与 -SHA384 选项相同的命令时，我在生成的 CSR 中得到：“签名算法：ecdsa-with-SHA384”。

键入此命令以查看支持的摘要列表：

openssl list-message-digest-algorithms

希望您会在该列表中看到 SHA384。

关于您的第二个问题，格式为 ASN.1。 “30”表示后面有一个序列（在这种情况下，它是一个由 2 个整数组成的序列）。 “65”是序列中的八位字节数。 “02”表示一个整数，30 是该整数中的八位字节数。如果您向前跳过 0x30（十进制的 48）八位字节，您将来到标有“02”和“31”的第二个整数。所以第一个整数的长度是 30，第二个是 31。将每个整数的 2 个八位字节相加，得到 65，这是序列的长度。这个page 可以告诉你更多关于 ASN.1 的信息。

只要这个值是 2 个整数的序列，这是有道理的。 ECDSA 签名由 2 个整数组成。有关详细信息，请参阅RFC6605 第 4 节。还有wiki page 解释了如何计算这两个整数。

【讨论】：

感谢您对签名格式的解释。它真的很有帮助。不幸的是，我正在运行 openssl 版本 0.9.8n，并且命令 list-message-digest-algorithms 在那里不可用。我发现我的内核中没有设置标志 CONFIG_CRYPTO_SHA256 和 CONFIG_CRYPTO_SHA512，所以我在打开这些标志的情况下再次构建它。但没有结果。我还在 openssl.cnf 的支持摘要列表中添加了 sha384，但它也没有帮助。
如果您输入“openssl dgst -foo”，您是否看到列出的 SHA386？ -foo 部分显然不是一个有效的参数，但用于显示用法，它也会列出摘要。另外，您是否尝试过使用 SHA256 或 SHA512 来查看它们是否有效？
输入 openssl dgst -foo 时会显示以下内容：“-sha384 to use the sha384 message digest algorithm”。是的，我也尝试过 SHA256 和 SHA512，我总是在签名算法中显示 ecdsa-with-SHA1。
有趣。如果您尝试像 -sha777 这样的无效选项怎么办？它会让你这样做还是会给你一个错误？新版本的 OpenSSL 怎么样？您可以下载最新的here。
还是关于签名格式（第2题）有一点不清楚； DSA 签名的两个整数中的每一个都可以是 48 (0x30) 字节长或 49 (0x31) 字节长。在第一种情况下，签名中的相关序列将从 02:30 开始：后跟 48 个字节 4e:b4:b6:..... 在第二种情况下，签名中的相关序列将从 02:31 开始: 后跟一个填充字节 00: 然后是 48 个字节 d7:a5:63:... 问题是什么原因有时有 0x00 字节填充，有时没有？

【解决方案3】：

为了让答案更完整，可以提一下带有ecdsa-sha384签名的非自签名证书的生成，因为有点不一样。诀窍是在“openssl ca”命令中使用“-md sha384”参数。

包含客户端证书的示例

为证书颁发机构生成密钥：

openssl ecparam -out ca.key -name secp384r1 -genkey

为 ca 创建自签名证书：

openssl req -x509 -new -key ca.key -out ca-ca.pem -outform pem -sha384

为客户端生成密钥：

openssl ecparam -out host1.key -name secp384r1 -genkey

为客户端密钥创建证书请求：

openssl req -new -nodes -key host1.key -outform pem -out host1.req -sha384

根据请求为客户创建证书：

openssl ca -keyfile ca.key -cert ca-ca.pem -in host1.req
  -out ca-host1-cert.pem -md sha384 -outdir .

【讨论】：