我正在使用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包含有关密钥的更详细信息，其中包含pub，Prime的部分， A，B，Generator，Order，Cofactor，Seed，但没有提到secp521r1。
但是，第二种方法生成的CSR仅包含pub和ASN1 OID: secp521r1。如果我要为HTTPS使用创建证书，这些差异是否很重要？
非常感谢！
答案 0 :(得分：1)
例如，当我使用openssl req -noout -text -in检查CSR时 sslcert.csr，第一种方法生成的CSR包含更多 关于密钥的详细信息，以及pub，Prime，A， B，发电机，订单，辅因子，种子，但没有提到 secp521r1。
这些被称为＆＃34;域参数＆＃34;。它们明确列出了模数，系数，发电机，公共点等。
但是，第二种方法生成的CSR只包含pub和 ASN1 OID：secp521r1。如果我正在创造，这些差异是否重要 用于HTTPS的证书？
像 ASN1 OID：secp521r1 这样的名称被称为＆＃34;命名曲线＆＃34;。
IETF的PKIX和TLS工作组称域名参数和命名曲线 不是 相同的东西。 PKIX组负责互联网的PKI和证书。在TLS工作组邮件列表上已就此进行了多次讨论。
如果您 不 使用命名曲线，那么即使域参数和命名曲线是，您的客户端和服务器也将无法相互连接当量。您将收到类似于＆＃34的错误;没有共享密码套件＆＃34;这将导致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上的Elliptic Curve Cryptography | Named Curves。
这两种方法似乎都创建了有效的CSR文件（我在这里测试了它们）。
他们有点做，但如果混合/匹配，他们就不会互操作。
为了获得现代兼容性，我已经使用了EC（
secp521r1）证书......
我最近没有对它进行过调查，但secp256r1是（最近？）最受欢迎的。 这可能已经改变但我不记得在任何地方阅读它。也许对Alexis前100万的扫描会给你一个想法或答案。
2016年论文TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication说：
查看ECDHE密钥交换中使用的椭圆曲线 显示97.2％的连接使用secp256r1曲线，其次是 使用secp384r1减少2％，使用sect571r1减少0.78％。