How to Create an ECC (ECDSA) SSL Certificate for Nginx

To create an ECC certificate for Nginx, generate an ECDSA private key, create a certificate-signing request (CSR) containing every required DNS name, obtain a certificate from a trusted certificate authority (CA), place the leaf certificate before its intermediate certificates in a PEM chain file, and point Nginx to that chain and the matching key. Test the configuration with nginx -t before every reload.

Antihost offers Linux VPS plans with full root access, unlimited traffic on a 1 Gbps port and a 14-day free trial.

ECC is commonly used as shorthand for an ECDSA certificate and its elliptic-curve private key. The process below covers public ACME issuance, manually submitted CSRs, laboratory self-signed certificates, Nginx curve selection, RSA/ECDSA coexistence, validation, renewal, and the failures that most often prevent a successful deployment.

#	Preview	Product	Price
1		Network Security: Private Communication in a Public World (Prentice Hall Series in Computer...	$63.20	Buy on Amazon
2		CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)	$41.83	Buy on Amazon
3		Cybersecurity For Dummies (For Dummies: Learning Made Easy)	$13.53	Buy on Amazon
4		Network Security, Firewalls, and VPNs	$66.62	Buy on Amazon
5		The Practice of Network Security Monitoring: Understanding Incident Detection and Response	$48.65	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

What an ECC certificate means in Nginx

Elliptic-curve cryptography is a family of algorithms. In an HTTPS server certificate, the relevant form is usually ECDSA: the certificate contains an elliptic-curve public key and is signed according to the CA’s policy. The corresponding private key must also be an EC key. Nginx does not need a special ECC directive; it reads the PEM-encoded certificate chain through ssl_certificate and the matching PEM private key through ssl_certificate_key.

The certificate’s curve is part of the compatibility decision. A client must support the certificate’s signature and key type, and Nginx/OpenSSL must be able to use the curve during the TLS handshake. An ECC certificate is therefore not automatically compatible with every old client or every old Nginx/OpenSSL build.

#1 Best Overall

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

Buy on Amazon

Prerequisites

• A hostname you control and a list of every DNS name that must appear in the certificate’s Subject Alternative Name (SAN) extension.
• Shell access to the Nginx host or to a controlled administration machine that can securely transfer the resulting files.
• OpenSSL with elliptic-curve key and CSR support. The -addext option used below is available only in versions that support it.
• An Nginx build with TLS support, permission to read the certificate and key files, and a way to reload the service safely.
• A renewal plan. A certificate that is installed correctly but allowed to expire is still an outage.

Choose how the certificate will be issued

Decide the trust and operating model before generating files. The key and CSR can be generated locally for any of these models, but the certificate returned by the issuer determines whether browsers and other clients trust it.

ACME and ECDSA details

When using a public ACME CA, select an ECDSA key type in the client or issuance profile rather than accepting an RSA default. Let’s Encrypt policy identifies ECDSA keys with the id-ecPublicKey algorithm identifier. When the signing key is P-256, the certificate signature uses ECDSA with SHA-256. The ACME client still has to install the returned leaf and intermediate files where your Nginx configuration expects them.

When a self-signed certificate is acceptable

A self-signed certificate can be useful when every test client is under your control and you can install your own trust anchor. It will produce browser warnings and trust failures elsewhere. Do not use it as a substitute for a publicly trusted chain on an Internet-facing production hostname.

Generate an ECDSA private key and CSR

Run the following as the account that manages private keys. The restrictive umask prevents newly created files from being readable by unrelated users.

1. Create a private directory

   Choose a directory that is not served as web content, set a restrictive umask, and create a hostname-specific location:

   umask 077
   mkdir -p /etc/nginx/tls/example.com
   cd /etc/nginx/tls/example.com

2. Generate the EC private key

   The example uses the widely deployed P-256 curve, called prime256v1 by OpenSSL:

   ×

   The Tool Desk

   Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →
   Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

   Rank #2

   Sale

   

   CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

   $41.83

   Buy on Amazon

   openssl ecparam -name prime256v1 -genkey -noout -out example.com.key

   The resulting example.com.key is the credential that proves control of the certificate’s public key. Never send it to the CA, place it in a ticket, or copy it into a web-accessible directory.

3. Create a CSR with SAN entries

   Put every required DNS name in the SAN extension. The common name alone is not a substitute for SANs:

   openssl req -new -sha256 -key example.com.key -out example.com.csr 
     -subj '/CN=example.com' 
     -addext 'subjectAltName=DNS:example.com,DNS:www.example.com'

   Replace the names with the hostnames that will actually be served. If the installed OpenSSL does not recognize -addext, place the SAN extension in an OpenSSL configuration file and pass that file with -config when creating the CSR. Do not assume that adding a name to Nginx’s server_name later will add it to an already issued certificate.

4. Submit only the CSR

   Send example.com.csr to the public CA, ACME client, or internal CA according to its enrollment procedure. Keep the private key on the server or controlled administration host. After validation, obtain the leaf certificate and the CA’s intermediate certificate bundle in PEM format.

   ×

   What’s actually slowing this PC down?

   Pick the symptom - the matching free tool is one click away.

   Outdated driversFree fix →Crashes & glitchesFree fix →System errors & instabilityFree fix →Junk files & broken settingsFree fix →
   Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

Build the certificate chain in the required order

Nginx expects the file named by ssl_certificate to contain the server’s leaf certificate first, followed by the intermediate certificate or certificates. The order matters: a chain assembled incorrectly can make Nginx refuse to start or can leave clients unable to build a trusted path.

After receiving the files, concatenate them without changing their PEM boundaries:

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

cat cert.pem intermediate.pem > fullchain.pem
chmod 600 example.com.key
chmod 644 fullchain.pem

If the CA supplied more than one intermediate, append each one after the leaf in the order specified by that CA. The private key should be readable only by the account that needs it, while the chain can normally be world-readable if the directory permissions allow Nginx to traverse the path. Keep backups of the old key and chain outside the document root so a failed renewal can be diagnosed or restored.

Configure the Nginx HTTPS server

Add the certificate and key to the TLS-enabled server block for the hostname:

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/nginx/tls/example.com/fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/example.com/example.com.key;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ecdh_curve auto;

    root /var/www/example.com;
    index index.html;
}

What each TLS directive does

• listen 443 ssl; enables TLS on the standard HTTPS port for this server block.
• server_name selects the virtual host, but it does not change the certificate’s SAN list.
• ssl_certificate must point to the PEM chain with the leaf first and intermediates after it.
• ssl_certificate_key must point to the private key that generated the public key in the leaf certificate.
• ssl_protocols TLSv1.2 TLSv1.3; limits negotiation to these protocols where the installed Nginx and OpenSSL versions support them.
• ssl_ecdh_curve controls the elliptic-curve groups offered for key exchange. It is separate from the certificate file, but the certificate’s curve must be available to the TLS stack.

Choose a curve policy

ssl_ecdh_curve auto; lets Nginx and OpenSSL choose from their supported groups. This is a practical default when the server and client population are not governed by a narrow compatibility policy.

If you need an explicit policy, Nginx documents a list such as prime256v1:secp384r1. Include the curve used by the ECDSA certificate and verify that the installed build supports every named group. Excluding the certificate’s curve can prevent ECDSA from working even though the certificate and key files are otherwise correct.

Serve RSA and ECDSA certificates together

ECDSA-only deployment reduces the choices available to clients that do not support ECDSA. Nginx can offer both certificate families when the version supports repeated certificate directives:

ssl_certificate     /etc/nginx/tls/example.com/fullchain-ecdsa.pem;
ssl_certificate_key /etc/nginx/tls/example.com/ecdsa.key;
ssl_certificate     /etc/nginx/tls/example.com/fullchain-rsa.pem;
ssl_certificate_key /etc/nginx/tls/example.com/rsa.key;

Nginx has supported repeating these directives for different certificate types, such as RSA and ECDSA, since version 1.11.0. Separate certificate chains for the two certificates require OpenSSL 1.0.2 or newer. Each certificate must have its own matching key and complete chain. Clients and the TLS stack can then select the family they support instead of forcing every connection to use ECDSA.

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

Validate the files before reloading Nginx

Validation should be a stop condition, not a formality. Inspect the certificate, confirm the key relationship, and test the complete Nginx configuration before replacing the running process.

1. Inspect the certificate metadata

   openssl x509 -in fullchain.pem -noout -subject -issuer -dates -text

   Check that the first certificate is the intended leaf, the SAN extension contains every production hostname, the issuer is the CA you selected, and the validity dates cover the planned service period.

2. Check the private-key relationship

   openssl pkey -in example.com.key -pubout -outform pem | sha256sum

   For a mismatch investigation, extract the public key from the leaf certificate and compare its hash with the command above:

   openssl x509 -in cert.pem -pubkey -noout | sha256sum

   The public-key outputs must match. A key from another hostname, an old renewal, or a file overwritten by an automation job will produce a mismatch even when both files are valid PEM.

   ×

   Quick wins for a faster PC:

   Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →
   Special offer. See more information about Outbyte and uninstall instructions. Please review EULA and Privacy policy.

3. Test the Nginx configuration

   nginx -t

   Run the test with the privileges required to read the configured files. Treat any error as a reason not to reload. Fix the reported path, permission, PEM-format, chain-order, curve, or key-mismatch problem first.

Reload safely and keep a rollback path

Only reload after nginx -t reports a successful configuration test:

Best Value

Sale

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

• Used Book in Good Condition

$48.65

Buy on Amazon

systemctl reload nginx

A reload asks the running master process to open the new files while existing connections finish. Keep the previous certificate and key in a protected backup location until the live endpoint has been checked. If the new files fail validation, do not force a reload; restore the known-good files, run nginx -t again, and reload only after the test passes.

Verify the certificate that clients actually receive

Local file inspection cannot prove that the intended virtual host is serving the intended chain. Query the public hostname with SNI:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

Review the certificate subject, SANs, issuer, validity dates, and the certificates sent after the leaf. Confirm that the negotiated protocol is one you intended to permit and that the intermediate certificate is delivered to clients. A browser check from a separate network is useful for catching DNS, load-balancer, or virtual-host routing mistakes that a local file test cannot see.

If the command shows a certificate for another hostname, check that the request includes the correct -servername value and that the matching Nginx server_name block is enabled. If the chain is incomplete, rebuild the chain file from the CA’s leaf and intermediate files and repeat the configuration test before reloading.

Plan renewal before the certificate expires

Public certificates are time-limited, so installation is only half of the operation. An ACME client can generate or reuse an ECDSA key, obtain a replacement certificate, and write a new chain. A manual CA workflow requires a scheduled reminder and a documented replacement procedure.

Recommended renewal sequence

1. Run the ACME or CA renewal process far enough ahead of expiry to allow for validation failures and DNS or firewall corrections.
2. Write the renewed leaf and intermediate certificates to temporary files, then assemble the production fullchain.pem with the leaf first.
3. Preserve restrictive ownership and permissions on the private key and ensure the Nginx master process can read both configured paths.
4. Run nginx -t against the complete configuration.
5. Reload only after the test succeeds, preferably from a deploy hook that stops on a failed test.
6. Query the live endpoint and confirm that the new dates, SANs, issuer, and chain are being served.

Use an atomic file replacement strategy where possible: write and validate the new files first, then move them into the configured paths. This prevents Nginx from reading a partially written PEM file during a renewal job. Automatic rotation is a feature of some managed Nginx certificate services, but verify that the service explicitly supports ECC/ECDSA and documents whether a reload is required.

Troubleshoot common ECC certificate failures

Decide between ECC-only and dual-certificate deployment

Choose ECC-only when your measured client population and infrastructure support it and the simpler certificate set is valuable. Choose both families when compatibility with unknown or legacy clients matters more than minimizing renewal files. In either case, test the live endpoint rather than assuming that a syntactically valid configuration proves interoperability.

Operational acceptance checklist

• The private key is stored outside web content with restrictive ownership and permissions.
• The CSR SAN list exactly covers the hostnames clients use.
• The CA-issued leaf and all required intermediates are in one PEM chain, with the leaf first.
• The configured certificate and key form a matching pair.
• The certificate curve is supported by the Nginx/OpenSSL build and included by the curve policy.
• nginx -t succeeds before every reload.
• An SNI-aware live check confirms the expected certificate, protocol, dates, and intermediate chain.
• Renewal writes complete files, validates them, reloads only on success, and alerts before expiry.

Following this sequence gives Nginx the three things an ECC deployment depends on: a valid ECDSA key and certificate pair, a correctly ordered trust chain, and a TLS configuration whose curve and client-compatibility policy match the certificate you issued.

Quick Recap

Bestseller No. 1

Network Security: Private Communication in a Public World (Prentice Hall Series in Computer Networking and Distributed Systems)

$63.20

SaleBestseller No. 2

CompTIA Security+ Certification Kit: Exam SY0-701 (Sybex Study Guide)

$41.83

SaleBestseller No. 3

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

SaleBestseller No. 4

Network Security, Firewalls, and VPNs

$66.62

SaleBestseller No. 5

The Practice of Network Security Monitoring: Understanding Incident Detection and Response

Used Book in Good Condition

$48.65

Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.