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

To use an ECC certificate with Nginx, generate an ECDSA private key and CSR, obtain a publicly trusted certificate containing the required subject alternative names, place the leaf certificate before its intermediate certificates in a PEM chain file, then reference that chain and the matching key with ssl_certificate and ssl_certificate_key. Set a compatible elliptic-curve policy, test the configuration with nginx -t, and reload only after the test succeeds.

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

What an ECC certificate means in Nginx

“ECC SSL certificate” normally means an X.509 certificate whose public key uses elliptic-curve cryptography and whose authentication key is ECDSA. The certificate is not a different Nginx object or file type: Nginx reads a PEM-encoded certificate chain and a PEM-encoded private key just as it does for an RSA certificate.

#	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.16	Buy on Amazon

As an Amazon Associate I earn from qualifying purchases.

The important pairing is the ECDSA leaf certificate with its matching elliptic-curve private key. A certificate issued for one public key cannot be used with another key, even when both keys use the same curve. Nginx loads the files through these directives:

• ssl_certificate points to the PEM file containing the server certificate followed by intermediate certificates.
• ssl_certificate_key points to the corresponding private key.

For a public website, obtain the certificate from a publicly trusted certificate authority (CA), normally through ACME or another CA enrollment process. A self-signed certificate is suitable only for a lab or an internal environment where you control installation of the trust anchor; it is not a replacement for a public CA chain on an Internet-facing site.

#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

Choose an issuance approach

When a public CA issues an ECDSA certificate, the certificate identifies the key with the id-ecPublicKey algorithm identifier. For a P-256 signing key, the signature uses ECDSA with SHA-256. The CA, rather than Nginx, determines the final certificate signature and validity period.

Prerequisites and decisions before generating the key

• Administrative access to the server or to a controlled administration host where the private key can be generated securely.
• OpenSSL with elliptic-curve key-generation and CSR support.
• Nginx built with TLS support and an OpenSSL version appropriate for the certificate features you intend to use.
• A list of every DNS name clients will use, such as example.com and www.example.com. Each name must appear in the certificate’s subject alternative name (SAN) extension.
• A CA enrollment method, such as an ACME client, or a CA that accepts a manually submitted CSR.
• A renewal plan that can replace the certificate and chain before expiration, test the Nginx configuration, and reload Nginx.

Choose the curve with your client population and policy in mind. P-256 is commonly represented by OpenSSL as prime256v1; P-384 is represented as secp384r1. Do not assume every legacy client supports ECDSA. If compatibility with older or unusual clients matters, plan for a dual RSA/ECDSA deployment rather than silently excluding those clients.

Generate an ECDSA private key and CSR with OpenSSL

The following example creates a P-256 key and a CSR for two hostnames. Run it on the server or on a tightly controlled administrative host. The restrictive umask prevents newly created files from being readable by other users.

umask 077
mkdir -p /etc/nginx/tls/example.com
cd /etc/nginx/tls/example.com
openssl ecparam -name prime256v1 -genkey -noout -out example.com.key
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"

What each command does

1. umask 077 limits permissions on files created by the shell session to the account that owns them.
2. mkdir creates a dedicated directory for this hostname’s key and certificate files. Keep the directory access-controlled.
3. openssl ecparam -name prime256v1 -genkey generates an ECDSA private key on the P-256 curve. The private key is written to example.com.key; it must never be sent to the CA.
4. openssl req -new -sha256 creates a CSR using that key. The CSR contains the public key and requested identity information, not the private key.
5. -addext adds SAN entries for both DNS names. The common name is not a substitute for SANs.

If your OpenSSL build does not support -addext, put the SAN extension in an OpenSSL configuration file and pass that file with -config. Make sure the resulting CSR actually contains every required DNS name before submitting it.

Send only example.com.csr to the CA or ACME enrollment process. Keep example.com.key private, back it up through a protected mechanism if your operations policy requires backups, and do not paste it into tickets, chat, or source control.

Rank #2

Sale

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

$41.83

Buy on Amazon

Obtain the certificate and assemble the full chain

After the CA validates control of the hostname, it returns a server (leaf) certificate and usually one or more intermediate certificates. Obtain them in PEM format. The file Nginx serves must put the leaf certificate first and the intermediate certificate or certificates immediately after it.

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

If there are multiple intermediates, append them in the order specified by the CA, beginning with the intermediate that signed the leaf and continuing toward the CA root. Do not normally include a root certificate in the server chain unless the CA specifically instructs you to do so.

Chain order is operationally significant. Nginx documentation requires intermediate certificates to follow the primary certificate in the same file; an incorrectly ordered chain can prevent Nginx from starting. A chain file containing only the leaf may work for some clients that already possess the intermediate, but it can fail for clients that need the server to provide that intermediate.

Keep the private key more restrictive than the public chain. The Nginx master process must be able to read the key during startup or reload, while ordinary users should not be able to read it. Adjust ownership and group permissions to match the account that manages Nginx on your system.

Configure an HTTPS server block

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

Rank #3

Sale

Cybersecurity For Dummies (For Dummies: Learning Made Easy)

$13.53

Buy on Amazon

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;
}

Understand the TLS settings

• listen 443 ssl; enables TLS on the standard HTTPS port for this server block.
• server_name must match the names in the certificate SAN list and the hostname clients send with SNI.
• ssl_certificate must reference the full chain with the leaf first.
• ssl_certificate_key must reference the ECDSA private key that matches the leaf certificate.
• ssl_protocols TLSv1.2 TLSv1.3; enables these protocol versions where supported by your Nginx and OpenSSL build. Do not enable obsolete protocols merely to make an old client work without understanding the security trade-off.
• ssl_ecdh_curve auto; lets Nginx choose a suitable supported group. For ECDSA to work, the curve used by the certificate must be included in the configured curve set.

If your compatibility policy requires an explicit list and your build supports the groups, use a setting such as:

ssl_ecdh_curve prime256v1:secp384r1;

An explicit policy is useful when you have documented client requirements, but it creates a responsibility: every ECDSA certificate you deploy must use a curve present in that list. Changing the certificate curve without changing the Nginx setting can make handshakes fail.

Serve RSA and ECDSA certificates together when necessary

An ECDSA-only site can be efficient and secure, but client compatibility is not universal. Nginx versions from 1.11.0 onward can repeat the certificate and key directives to load certificates of different types, such as RSA and ECDSA. Separate certificate chains for those certificates require OpenSSL 1.0.2 or newer.

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

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

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

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ecdh_curve auto;
}

Nginx and the TLS library select the certificate appropriate for the client’s capabilities. Maintain each key, leaf certificate, and chain as a matching set. Renewing one family does not renew the other, so your automation must test and reload after both sets are updated when both are deployed.

Verify the key, certificate, and chain before reloading

Do not reload a production Nginx process until the configuration test succeeds. First inspect the certificate and confirm the key relationship:

Rank #4

Sale

Network Security, Firewalls, and VPNs

$66.62

Buy on Amazon

openssl pkey -in example.com.key -pubout -outform pem | sha256sum
openssl x509 -in fullchain.pem -noout -subject -issuer -dates -text
nginx -t

Checks to perform

• Compare the public-key output derived from the private key with the public key in the leaf certificate if you suspect a key mismatch. A mismatch means the files are not a pair; obtain the correct certificate or use the key that generated the CSR.
• Read the SAN extension in the certificate and confirm that every production hostname is present. A correct common name alone does not cover an omitted SAN.
• Check the notBefore and notAfter dates. A certificate that is not yet valid, already expired, or replaced with the wrong renewal can cause client failures.
• Check the issuer and the chain files. Confirm that the intermediate is the one supplied or specified by your CA and that the leaf is the first certificate in fullchain.pem.
• Confirm that the paths in the server block point to the files you actually updated and that the Nginx master process can read the private key.
• Read the complete output of nginx -t. Treat any failure as a stop condition.

Only after a successful test should you apply the files:

systemctl reload nginx

A reload asks Nginx to read the new configuration while existing connections continue where possible. If the test fails, do not reload blindly. Correct the path, permissions, PEM formatting, chain order, curve setting, or key mismatch first.

Verify what the live endpoint serves

After the reload, connect using the real hostname, not merely an IP address, so that SNI selects the intended server block. Inspect the endpoint with an OpenSSL client or a browser and verify:

• The served leaf certificate has the expected subject alternative names and validity dates.
• The issuer and intermediate chain are the ones you installed.
• The negotiated protocol is TLS 1.2 or TLS 1.3 according to your policy.
• The endpoint presents the ECDSA certificate when the client supports it, or the appropriate RSA certificate when you configured both families.
• Clients receive the intermediate certificate instead of having to discover it independently.

If the browser still shows the old certificate immediately after a reload, check that the request reached the correct host, that another Nginx instance or proxy is not terminating TLS, and that the server block loaded by the running process is the one you edited.

Renewal and replacement workflow

ECDSA certificates expire like other publicly trusted certificates. Renewal is not complete when a CA or ACME client has downloaded a new file; Nginx must read that file. Build renewal around these steps:

Best Value

Sale

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

• Used Book in Good Condition

$48.16

Buy on Amazon

1. Renew through the CA or ACME client before the current certificate expires.
2. Install the new leaf and intermediate files, preserving leaf-first order in the chain.
3. Keep the existing private key only if your policy allows key reuse and the renewed certificate was issued for that key. If a new key was generated, verify the new certificate against that new key.
4. Run the certificate inspection and nginx -t checks.
5. Reload Nginx only after the test passes.
6. Check the live endpoint and record a failure or success signal for monitoring.

Automated renewal should have a deploy or post-renewal hook that performs the test and reload, with failure alerting. Test the renewal path before the first emergency renewal window; a timer that downloads files without installing them into the paths Nginx uses is not an effective deployment.

Troubleshooting common failures

“Private key does not match certificate”

The certificate and key are from different requests or one file was replaced during renewal. Derive and compare their public keys, then restore the matching pair. Do not try to repair a mismatch by changing Nginx directives; the cryptographic objects themselves must match.

Nginx reports a PEM or certificate-loading error

Check that the files are PEM text, that the paths are correct, and that the files contain complete BEGIN CERTIFICATE/END CERTIFICATE blocks. Inspect permissions and ownership so the Nginx master can read the key. A binary certificate, truncated transfer, or accidental inclusion of unrelated text can all cause parsing errors.

Nginx fails after adding the chain

Inspect the order of certificates in fullchain.pem. The leaf must be first, followed by its intermediate certificates. Also verify that the chain belongs to that leaf and that you did not concatenate a private key or an unrelated certificate into the chain file.

Handshake fails only for some clients

Check the client’s TLS and elliptic-curve capabilities. The certificate curve must be supported by the configured ssl_ecdh_curve and by the client. Older clients may not support ECDSA at all; serving matching RSA and ECDSA pairs can address that compatibility requirement when your Nginx and OpenSSL versions support repeated certificate directives.

The browser reports a name or trust error

Confirm the requested hostname is in the SAN extension, that the server is presenting the intended certificate, and that the intermediate chain is complete and correctly ordered. A self-signed certificate will remain untrusted on clients that have not been configured with your private trust anchor.

The new certificate is not visible

Verify that the renewal process wrote to the exact paths in ssl_certificate and ssl_certificate_key, run nginx -t, reload Nginx, and inspect the live endpoint again. If a load balancer, reverse proxy, or second server terminates TLS, update and verify that TLS endpoint as well.

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.16

Operational checklist

• Use an ECDSA private key and CSR, and submit only the CSR to the CA.
• Include every required hostname as a SAN.
• Keep the private key restricted and separate from publicly readable certificate files.
• Build the chain with the leaf first and intermediates afterward.
• Match the certificate curve to ssl_ecdh_curve and the clients you must support.
• Use TLS 1.2 and TLS 1.3 where your supported Nginx/OpenSSL build permits.
• Run nginx -t before every reload.
• Verify the live certificate, protocol, and chain after every issuance or renewal.
• Choose RSA plus ECDSA certificates when an ECDSA-only deployment would exclude required clients.
• Monitor expiration and make renewal automation fail loudly when validation or reload does not succeed.

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.