ssl - 创建 EC CSR 时命名曲线或域参数

Question

我正在使用 OpenSSL 为新证书创建 CSR。为了与现代兼容，我使用了 EC (secp521r1) 证书。在四处搜索时，我发现了两种不同的创建 CSR 的方法。

我可以显式创建私钥

openssl ecparam -name secp521r1 -genkey -param_enc explicit -out private.key
openssl req -new -sha256 -nodes -key private.key -out sslcert.csr -config san.cnf

或者我可以根据请求创建私钥

openssl ecparam -name secp521r1 > ec.file
openssl req -new -sha256 -nodes -newkey ec:ec.file -keyout private.key -out sslcert.csr -config san.cnf

这两种方法似乎都能创建有效的 CSR 文件(我已经对它们进行了测试 here)。

我的问题是上述方法中的一种是否更好/更安全？我注意到第一种方法生成的私钥文件比较大，CSR文件也比较大。

例如，当我使用 openssl req -noout -text -in sslcert.csr 检查 CSR 时，第一种方法生成的 CSR 包含关于 key 的更多详细信息，有一个部分对于 pub、Prime、A、B、Generator、Order ，Cofactor，Seed，但是没有提到secp521r1。

然而，第二种方法生成的 CSR 仅包含 pub 和一个 ASN1 OID: secp521r1。如果我要创建用于 HTTPS 的证书，这些差异是否重要？

非常感谢!

Answer 1

For example, when I inspect the CSR using openssl req -noout -text -in sslcert.csr, the CSR generated by the first method contains much more detailed information about the key, with a section for pub, Prime, A, B, Generator, Order, Cofactor, Seed, but there is no mention of secp521r1.

这些被称为“域参数”。他们明确列出了模数、系数、生成器、公共(public)点等。

However, the CSR generated by the second method contains only pub and a ASN1 OID: secp521r1. Are these differences important if I'm creating certificates for HTTPS use?

像ASN1 OID: secp521r1 这样的名称被称为“命名曲线”。

IETF 的 PKIX 和 TLS 工作组表示域参数和命名曲线不是一回事。 PKIX 组负责互联网的 PKI 和证书。在 TLS 工作组邮件列表中已经就此进行了多次讨论。

如果您不使用命名曲线，那么即使域参数和命名曲线相同，您的客户端和服务器也将无法相互连接。您将收到类似于“无共享密码套件”的错误，这将导致 TLS 警报。

以下是在测试期间使用 s_client 和 s_server 时如果您将域参数与命名曲线混合和匹配时出现的错误:

客户端 (s_client):

139925962778272:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1256:SSL alert number 40
139925962778272:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:

服务器(s_server):

140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353:

为了互操作性，您应该始终明确设置named_curve。另见 Elliptic Curve Cryptography | Named Curves在 OpenSSL wiki 上。

---

Both of these methods seem to create valid CSR files (I have tested them here).

它们有点像，但如果它们混合/匹配，它们就不能很好地互操作。

---

For modern compatibility, I've gone with EC (secp521r1) certificates...

我最近没有调查过它，但是 secp256r1 是(过去是？)最受欢迎的一个。 那可能已经改变了，但我不记得在任何地方读过它。也许对 Alexis 前 100 万名的扫描会给你一个想法或答案。

2016年论文TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication说:

Looking at the elliptic curves that are used in ECDHE key exchanges reveals that 97.2% of connections use the secp256r1 curve, followed by 2% using secp384r1 and 0.78% using sect571r1.