我正在使用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文件(我在这里测试了它们)。
我的问题是上述方法之一是否更好/更安全？我注意到第一种方法生成的私钥文件更大，CSR 文件也更大。
例如，当我使用openssl req -noout -text -in sslcert.csr检查CSR时，第一种方法生成的CSR包含有关密钥的更详细的信息，其中有一节是pub，Prime，A，B，Generator，Order，Cofactor，Seed，但没有提到secp521r1。
但是，第二种方法生成的 CSR 仅包含pub和ASN1 OID: secp521r1。如果我创建用于 HTTPS 的证书，这些差异是否重要？
非常感谢！
，当我使用 openssl req -noout -text -in 检查 CSR 时 sslcert.csr，第一种方法生成的 CSR 包含更多 有关密钥的详细信息，包括酒吧，Prime，A， B，生成器，订单，辅助因子，种子，但没有提到 secp521r1.
这些参数称为"域参数"。它们明确列出了模量、系数、生成器、公共点等。
但是，第二种方法生成的 CSR 仅包含 pub 和 a ASN1 OID：secp521r1。如果我正在创建，这些差异是否重要 用于 HTTPS 的证书？
像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。另请参阅椭圆曲线加密 |OpenSSL wiki 上的命名曲线。
这两种方法似乎都可以创建有效的CSR文件(我在这里测试了它们)。
它们确实如此，但如果它们混合/匹配，则无法很好地互操作。
为了现代兼容性，我使用了EC(
secp521r1)证书...
我最近没有调查过它，但secp256r1(曾经？)是最受欢迎的一个。这可能已经改变，但我不记得在任何地方读过它。也许扫描亚历克西斯的前100万会给你一个想法或答案。
2016年的论文TLS在野外：基于TLS的电子通信协议的互联网分析说：
查看 ECDHE 密钥交换中使用的椭圆曲线 显示 97.2% 的连接使用 SECP256R1 曲线，遵循 使用 secp384r1 减少 2%，使用 sect571r1 减少 0.78%。