<blockquote>
  <p>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.</p>
</blockquote>

<p>These are called "domain parameters". They explicitly list the modulus, the coefficients, the generator, the public point, etc.</p>

<blockquote>
  <p>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?</p>
</blockquote>

<p>A name like <em>ASN1 OID: secp521r1</em> is called a "named curve".</p>

<p>The IETF's PKIX and TLS working group say domain parameters and named curves <strong><em>are not</em></strong> the same thing. The PKIX group is responsible for the internet's PKI and certificates. There have been several discussions about this on the TLS working group mailing lists.</p>

<p>If you <strong><em>don't</em></strong> use a named curve, then your clients and servers will fail to connect to one another even the the domain parameters and named curves are equivalent. You will get errors similar to "no shared cipher suites" which will result in a TLS alert.</p>

<p>Here are the errors you get when using <code>s_client</code> and <code>s_server</code> during testing if you mix and match domain parameters with named curves:</p>

<p><em>Client (s_client)</em>:</p>

<pre><code>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:
</code></pre>

<p><em>Server (s_server)</em>:</p>

<pre><code>140339533272744:error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher:s3_srvr.c:1353:
</code></pre>

<p>For interoperability you should <em>always</em> explicitly set <code>named_curve</code>. Also see <a href="https://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves" rel="nofollow noreferrer">Elliptic Curve Cryptography | Named Curves</a> on the OpenSSL wiki.</p>

<hr>

<blockquote>
  <p>Both of these methods seem to create valid CSR files (I have tested them here).</p>
</blockquote>

<p>They kind of do, but they don't inter-operate well if they are mixed/matched.</p>

<hr>

<blockquote>
  <p>For modern compatibility, I've gone with EC (<code>secp521r1</code>) certificates...</p>
</blockquote>

<p>I have not surveyed it recently, but <code>secp256r1</code> is (was?) the most popular one. <strike>That may have changed but I don't recall reading it anywhere. Maybe a scan of the Alexis top 1 Million will give you an idea or answer.</strike></p>

<p>The 2016 paper <a href="https://arxiv.org/pdf/1511.00341.pdf" rel="nofollow noreferrer">TLS in the wild: An Internet-wide analysis of TLS-based protocols for electronic communication</a> says:</p>

<blockquote>
  <p>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.</p>
</blockquote>
Named curves or domain parameters when creating an EC CSR
<p>I'm creating CSRs for new certificates using OpenSSL. For modern compatibility, I've gone with EC (<code>secp521r1</code>) certificates. While googling around, I found two different ways of creating the CSR.</p>

<p><strong>I can create a private key explicitly</strong></p>

<pre><code>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
</code></pre>

<p><strong>or I can create a private key with the request</strong></p>

<pre><code>openssl ecparam -name secp521r1 &gt; ec.file
openssl req -new -sha256 -nodes -newkey ec:ec.file -keyout private.key -out sslcert.csr -config san.cnf
</code></pre>

<p>Both of these methods seem to create valid CSR files (I have tested them <a href="http://www.entrust.net/ssl-technical/csr-viewer.cfm" rel="nofollow noreferrer">here</a>).</p>

<p>My question is whether one of the methods above is better/safer? I noticed that the private key file generated by the first method is larger, and so is the CSR file.</p>

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

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

<p>Many thanks!</p>