DEV Community: Dima Stopel

Why Subject Alternative Names (SANs) Matter for Modern Browsers

Dima Stopel — Wed, 06 May 2026 12:38:15 +0000

Why Subject Alternative Names (SANs) Matter for Modern Browsers

The single most common reason self-signed certs stop working in browsers — and the fix.

For two decades, SSL/TLS certificates identified themselves via the Common Name (CN) field in the Subject Distinguished Name. Today, browsers ignore it completely. If your certificate doesn't have a Subject Alternative Name (SAN) matching the hostname, every modern browser will reject it — even if the CN is exactly right.

The short version

When you visit https://example.com, the browser checks the server's certificate for a SAN entry containing example.com. If no SAN matches, the connection is rejected with an error like NET::ERR_CERT_COMMON_NAME_INVALID. The Common Name is not consulted.

When did this change?

2000: RFC 2818 says "if a subjectAltName extension of type dNSName is present, that MUST be used as the identity. Otherwise, the (most specific) Common Name field in the Subject field of the certificate MUST be used."
2012: CA/Browser Forum Baseline Requirements mandate SANs for CA-issued certs.
2017 (Chrome 58): Chrome removes the CN fallback. Firefox follows shortly after. Safari had never accepted CN-only certs.
Today: Every major browser ignores CN.

What a SAN looks like

The SAN is an X.509 extension. In a certificate, it might look like:

X509v3 Subject Alternative Name:
    DNS:example.com
    DNS:www.example.com
    DNS:*.dev.example.com
    IP:127.0.0.1
    IP:192.168.1.1

Paste any certificate into our PEM decoder to see its SAN entries.

Generating a cert with SANs

With cert-depot.com: just list each SAN on its own line in the SANs field. The CN is automatically included as a SAN; you only need to list additional names (other domains, wildcards, IPs).

With OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout key.pem -out cert.pem -days 365 \
  -subj "/CN=example.com" \
  -addext "subjectAltName=DNS:example.com,DNS:*.example.com,IP:127.0.0.1"

The -addext flag was added in OpenSSL 1.1.1 (2018). On older versions, you need a config file.

Types of SAN you can include

dNSName — a domain like example.com or wildcard *.example.com. Wildcards match exactly one label.
iPAddress — a literal IPv4 or IPv6 address. Useful for direct-to-IP testing.
uniformResourceIdentifier — a URI. Used for OCSP responder URLs, not hostname matching.
rfc822Name — an email address. Used for S/MIME, not TLS.

Wildcard rules

A wildcard like *.example.com matches foo.example.com but not:

example.com itself (the apex)
foo.bar.example.com (deeper subdomains)

Practical implication: include both example.com and *.example.com as separate SAN entries to cover both cases.

Can the CN still be set?

Yes — and it's often set to the primary domain for readability in cert listings. But browsers ignore it. Set it to whatever the primary name is, and make sure that same name is in the SAN list.

How to Trust a Self-Signed Certificate on Windows

Dima Stopel — Wed, 06 May 2026 12:31:39 +0000

How to Trust a Self-Signed Certificate on Windows

Add your certificate to the Windows Trusted Root store — the GUI and PowerShell ways.

Windows maintains certificate stores for both the current user and the local machine. For a certificate to be trusted system-wide, install it into Local Machine › Trusted Root Certification Authorities.

Method 1: Double-click (easiest)

Rename your certificate to .crt if it's .pem (Windows recognizes both, but .crt triggers the install dialog on double-click).
Double-click the file. The Certificate dialog opens.
Click Install Certificate….
Select Local Machine (requires admin confirmation). Click Next.
Choose Place all certificates in the following store, then Browse.
Select Trusted Root Certification Authorities, click OK, then Next, then Finish.
Confirm the security warning dialog.

Method 2: PowerShell

Import-Certificate -FilePath "C:\path\to\certificate.crt" `
  -CertStoreLocation Cert:\LocalMachine\Root

To install for the current user only (no admin required):

Import-Certificate -FilePath "C:\path\to\certificate.crt" `
  -CertStoreLocation Cert:\CurrentUser\Root

Method 3: MMC (full control)

Press Win+R, type mmc, press Enter.
File › Add/Remove Snap-in › select Certificates, click Add.
Choose Computer account, click Next, then Finish.
Expand Trusted Root Certification Authorities › Certificates.
Right-click All Tasks › Import… — walk through the wizard.

Verify It Worked

certutil -store Root | findstr "Your Cert CN"

Or in PowerShell:

Get-ChildItem -Path Cert:\LocalMachine\Root | Where-Object { $_.Subject -match "your-domain.local" }

Restart Chrome/Edge and visit your HTTPS site — the padlock should be clean, no warning.

Removing the Certificate

# PowerShell — by thumbprint
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Subject -match "your-domain.local" } | Remove-Item

Troubleshooting

Cert installs but browser still shows warning

Fully close Chrome/Edge (check Task Manager) and restart. The trust store is cached in-process.

"The parameter is incorrect" during import

The file is probably not a valid X.509 certificate. Check with our PEM decoder — if it fails to parse there too, the file is corrupted or the wrong type (maybe a private key?).

Certificate has no SAN

Installing the cert as trusted doesn't bypass the SAN check. Browsers will still reject certs without a matching SAN. Regenerate with our generator.

How to Trust a Self-Signed Certificate on macOS

Dima Stopel — Wed, 06 May 2026 12:30:08 +0000

How to Trust a Self-Signed Certificate on macOS

Add your certificate to the macOS System keychain so Safari, Chrome, curl, and most other tools trust it.

macOS uses a unified keychain system that's shared across most applications — Safari, Chrome, curl, git, and many others. Adding your self-signed certificate once usually makes it trusted everywhere (Firefox is an exception; see our Firefox guide).

GUI: Keychain Access

Open Keychain Access (Spotlight: Cmd+Space, type "Keychain").
From the menu: File › Import Items.
Select your .pem or .crt file.
When asked which keychain, choose System (requires admin password). Choose login to trust it only for your user.
Find the imported certificate, double-click it.
Expand the Trust section.
Change "When using this certificate" to Always Trust.
Close the dialog — you'll be prompted for your password to save.

Command Line

For scripting or CI, use the security tool. This adds and fully trusts the cert in one step:

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain /path/to/certificate.pem

Flags explained: -d = admin domain, -r trustRoot = trust as root CA, -k = keychain path.

To remove it later:

sudo security delete-certificate -c "Your Certificate CN" \
  /Library/Keychains/System.keychain

Verify It Worked

Restart your browser (it caches the trust store at startup). Then use one of these:

# Inspect via curl
curl -I https://your-domain.local/

# Inspect the trust with security
security verify-cert -c certificate.pem

# View the cert that a server is serving
echo | openssl s_client -connect your-domain.local:443 2>/dev/null \
  | openssl x509 -noout -subject -issuer

Common Issues

Still getting "certificate not trusted" in Chrome

Fully quit Chrome (Cmd+Q) and reopen. Chrome only reads the trust store at startup.

Certificate has no SAN

Even when fully trusted in macOS, Chrome and Safari will reject certificates without a Subject Alternative Name matching the hostname. Use our generator which includes SANs, or regenerate with openssl using the -addext flag.

The cert imports but stays "Not Trusted"

You imported it to the login keychain without changing the trust setting. Double-click the cert in Keychain Access and set "Always Trust".

How to Trust a Self-Signed Certificate in Firefox

Dima Stopel — Wed, 06 May 2026 12:23:31 +0000

How to Trust a Self-Signed Certificate in Firefox

Firefox ignores the OS trust store by default. Here's how to add your cert to Firefox's own store.

Firefox is the only major browser that maintains its own certificate store separate from the operating system. Installing a cert in Keychain (macOS), Certificate Manager (Windows), or /etc/ssl/certs/ (Linux) won't affect Firefox.

Option 1: Enable OS trust store

Since Firefox 49, you can make Firefox honor the OS trust store via a preference:

Open about:config in Firefox.
Accept the warning.
Search for security.enterprise_roots.enabled.
Set it to true.
Restart Firefox.

Firefox will now trust certificates installed in the OS trust store. This is the easiest option if you've already installed the cert OS-wide.

Option 2: Import directly into Firefox

Use this if you only want Firefox to trust the cert (not the whole OS), or if the enterprise_roots option isn't working.

Open Firefox Settings.
Search for "certificates".
Click View Certificates….
Go to the Authorities tab.
Click Import…, select your .pem or .crt file.
Check Trust this CA to identify websites, click OK.
Restart Firefox (sometimes not required, but safer).

Option 3: Import via the warning page

When Firefox shows "Warning: Potential Security Risk Ahead" for your self-signed site:

Click Advanced….
Click Accept the Risk and Continue.

This adds an exception for that specific site, but only until you clear browsing data or the cert changes. For persistent trust, use Options 1 or 2.

Command line: certutil (for scripting)

Firefox's cert DB is an NSS database, editable with certutil from libnss3-tools (Linux) or the Firefox installation's bin/ directory (macOS/Windows).

Find the Firefox profile:

# Linux/macOS
ls ~/.mozilla/firefox/  # Linux
ls ~/Library/Application\ Support/Firefox/Profiles/  # macOS
# Pick the default profile, e.g. abcd1234.default-release

Add the cert:

certutil -A -n "My Cert" -t "C,," \
  -i certificate.pem \
  -d ~/.mozilla/firefox/abcd1234.default-release

The -t "C,," flag marks it as a trusted CA for SSL.

Verify it worked

Visit your HTTPS site in Firefox. The padlock should be solid (not grayed out or with a warning). Click the padlock and "Connection secure" — it should show your certificate's details.

Troubleshooting

Certificate imports but site still shows warning

You imported it as a server cert instead of a CA. Go back to View Certificates › Authorities (not Your Certificates or Servers) and re-import with the "Trust this CA" checkbox.

enterprise_roots doesn't seem to do anything

It only works for certificates marked as "Trusted Root CA" in the OS. If you installed your cert as a regular trusted cert (not a root), Firefox won't pick it up.

Cert is trusted but Firefox still complains about SANs

Trusting a cert doesn't bypass the SAN check. The certificate must include a Subject Alternative Name matching the hostname you're visiting. Check with our PEM decoder.

How to Trust a Self-Signed Certificate in Chrome

Dima Stopel — Wed, 06 May 2026 12:22:00 +0000

How to Trust a Self-Signed Certificate in Chrome

Remove the browser warning for your development certificates — on any OS.

Chrome doesn't have its own certificate store — it uses the operating system's trust store. Once you add your self-signed certificate to the OS, Chrome (and most other browsers) will trust it automatically. Firefox is the exception, and we cover it in a separate guide.

Prerequisites

You need the public certificate file (.crt or .pem). You do not need the private key on the client machine — only on the server.

macOS

Double-click the .crt or .pem file. Keychain Access will open.
When prompted, choose the System keychain (not login) so all users trust it.
Find the certificate in Keychain Access, double-click it.
Expand Trust, set "When using this certificate" to Always Trust.
Close the window — you'll be asked for your password to save.
Quit and restart Chrome.

From the command line

sudo security add-trusted-cert -d -r trustRoot \
  -k /Library/Keychains/System.keychain certificate.pem

Windows

Double-click the .crt file.
Click Install Certificate.
Choose Local Machine (requires admin), click Next.
Select Place all certificates in the following store and browse to Trusted Root Certification Authorities.
Click Next, then Finish. Confirm the security warning.
Restart Chrome.

PowerShell

Import-Certificate -FilePath "certificate.crt" `
  -CertStoreLocation Cert:\LocalMachine\Root

Linux (Ubuntu/Debian)

sudo cp certificate.pem /usr/local/share/ca-certificates/my-cert.crt
sudo update-ca-certificates

On Fedora/RHEL:

sudo cp certificate.pem /etc/pki/ca-trust/source/anchors/
sudo update-ca-trust

Chrome-specific NSS database (Linux only)

Chrome on Linux uses NSS, not the system trust store by default. To trust a cert just for Chrome:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," \
  -n "MyCert" -i certificate.pem

Install libnss3-tools (Debian/Ubuntu) or nss-tools (Fedora) if certutil is not available.

Verify It Worked

Visit your HTTPS site in Chrome. The padlock should be green (or gray) with no warning. If you still see the warning:

Fully quit Chrome and restart — it caches the trust store.
Check that the certificate has a matching SAN using our PEM decoder.
Confirm the hostname you're visiting exactly matches the SAN entry.

How Long Should a Self-Signed Certificate Be Valid?

Dima Stopel — Wed, 06 May 2026 12:14:50 +0000

How Long Should a Self-Signed Certificate Be Valid?

Why 398 days is the public-CA ceiling, why self-signed certs aren't bound by it, and what validity period you should actually pick.

When generating a self-signed cert, you set how long it's valid. Different tools default to different values: OpenSSL is 30 days, Let's Encrypt is 90 days, enterprise CAs used to issue for 10+ years. Here's how to think about it.

The 398-day browser limit

Since September 2020, Apple, Chrome, and Mozilla reject publicly-trusted SSL certificates valid for more than 398 days. This was a CA/Browser Forum policy change aimed at forcing faster rotation after incidents where CAs kept issuing problematic certs for years.

This limit applies to certificates chained to a browser-trusted root — in other words, Let's Encrypt, DigiCert, Sectigo, etc. It does not apply to certificates in a private trust chain, like self-signed certs or your own internal CA.

Self-signed certs can be any duration

Technically, you could issue a self-signed cert valid for 100 years. The browser-limit logic only kicks in for publicly-trusted chains. For dev and internal use, the duration you pick is entirely a tradeoff:

Too short — you're constantly regenerating and reinstalling.
Too long — if the private key leaks, the blast radius is huge.

Practical defaults

Local development on your laptop: 1–5 years

Set it and forget it. The private key sits on your development machine and rarely leaves it.

Internal tools / internal CA: 90 days to 1 year

Short enough to build rotation hygiene, long enough that you're not rotating weekly.

CI/CD or ephemeral test environments: 30–90 days

Matches the rotation cadence of the infrastructure it lives on.

Certificate authority root (your own internal CA): 10–20 years

Rotating a root is painful. Pick a long duration and protect the private key in a vault.

What browsers will accept from self-signed sources

A self-signed cert valid for 10 years is technically fine. But if a user decides to "trust" a 10-year cert in their OS, they're granting that cert authority for 10 years. Consider what happens if the server holding the private key is compromised in year 3.

For maximum safety, 1 year is a good ceiling. Renew annually with a script.

Reading the validity period of an existing cert

Use our PEM decoder, or:

openssl x509 -in cert.pem -noout -dates

Output:

notBefore=Apr  1 12:00:00 2026 GMT
notAfter=Apr  1 12:00:00 2027 GMT

Self-Signed SSL Certificate for Node.js HTTPS Server

Dima Stopel — Wed, 06 May 2026 12:13:20 +0000

Self-Signed SSL Certificate for Node.js HTTPS Server

Run a Node.js HTTPS server with a self-signed certificate — native, Express, and Fastify examples.

Node.js has built-in HTTPS support via the https module. You just need to load your certificate and key, and pass them as options to createServer.

Step 1: Generate the Certificate

Use cert-depot.com for a browser-friendly cert, or:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout key.pem -out cert.pem -days 365 \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1"

Native https module

const https = require("node:https");
const fs = require("node:fs");

const options = {
    key: fs.readFileSync("key.pem"),
    cert: fs.readFileSync("cert.pem"),
};

https.createServer(options, (req, res) => {
    res.writeHead(200, { "Content-Type": "text/plain" });
    res.end("Hello over TLS!\n");
}).listen(3443, () => {
    console.log("Listening on https://localhost:3443/");
});

Express

const express = require("express");
const https = require("node:https");
const fs = require("node:fs");

const app = express();
app.get("/", (req, res) => res.send("Hello over TLS!"));

https.createServer({
    key: fs.readFileSync("key.pem"),
    cert: fs.readFileSync("cert.pem"),
}, app).listen(3443, () => {
    console.log("Express listening on https://localhost:3443/");
});

Fastify

const fastify = require("fastify")({
    https: {
        key: require("node:fs").readFileSync("key.pem"),
        cert: require("node:fs").readFileSync("cert.pem"),
    },
});

fastify.get("/", async () => ({ hello: "world" }));
fastify.listen({ port: 3443 });

Making fetch / axios / node-fetch trust the certificate

By default, Node.js rejects self-signed certificates when acting as a client. For development only:

# Run with NODE_TLS_REJECT_UNAUTHORIZED=0 — insecure, dev only
NODE_TLS_REJECT_UNAUTHORIZED=0 node client.js

A better approach: point Node.js at the cert via NODE_EXTRA_CA_CERTS:

NODE_EXTRA_CA_CERTS=./cert.pem node client.js

Or pass it per-request with the ca option in https.Agent.

PFX / PKCS#12 alternative

Instead of separate key and cert, you can load a single PFX file:

https.createServer({
    pfx: fs.readFileSync("cert.pfx"),
    passphrase: "your-password",
}, app).listen(3443);

Our generator produces PFX files directly.

Self-Signed Certificates for localhost Development

Dima Stopel — Wed, 06 May 2026 12:06:43 +0000

Self-Signed Certificates for localhost Development

Stop clicking past browser warnings. Get a proper green-padlock HTTPS localhost in a few minutes.

Most modern web APIs require HTTPS: Service Workers, Web Crypto, geolocation, camera access, OAuth flows, HTTP/2. Developing locally against HTTP hits constant "feature unavailable" errors. A self-signed cert for localhost fixes this — but only if you trust it properly.

Step 1: Generate the certificate

With cert-depot.com: enter localhost as the Common Name, add 127.0.0.1 and ::1 as IP SANs, generate.

With OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout localhost.key -out localhost.crt \
  -days 365 \
  -subj "/CN=localhost" \
  -addext "subjectAltName=DNS:localhost,IP:127.0.0.1,IP:::1"

Step 2: Trust it in your OS

This is the step that makes the browser warning go away. Without it, you still get HTTPS (encrypted traffic), but the browser shows "Not Secure" and some APIs stay blocked.

Step 3: Serve it from your dev server

Vite

// vite.config.js
import fs from "node:fs";

export default {
    server: {
        https: {
            key: fs.readFileSync("localhost.key"),
            cert: fs.readFileSync("localhost.crt"),
        },
    },
};

Next.js (via custom server)

// server.js
const { createServer } = require("https");
const fs = require("fs");
const next = require("next");

const app = next({ dev: true });
const handle = app.getRequestHandler();

app.prepare().then(() => {
    createServer({
        key: fs.readFileSync("localhost.key"),
        cert: fs.readFileSync("localhost.crt"),
    }, handle).listen(3000);
});

webpack-dev-server

// webpack.config.js
module.exports = {
    devServer: {
        server: {
            type: "https",
            options: {
                key: "./localhost.key",
                cert: "./localhost.crt",
            },
        },
    },
};

Python (http.server replacement)

from http.server import HTTPServer, SimpleHTTPRequestHandler
import ssl

ctx = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ctx.load_cert_chain("localhost.crt", "localhost.key")

server = HTTPServer(("localhost", 4443), SimpleHTTPRequestHandler)
server.socket = ctx.wrap_socket(server.socket, server_side=True)
server.serve_forever()

Alternative: mkcert

mkcert automates the trust step by installing a local CA, then issuing certs from that CA. Install with:

brew install mkcert  # macOS
mkcert -install
mkcert localhost 127.0.0.1 ::1

It's convenient. The tradeoff is that mkcert installs its own root CA on your machine — meaning anyone who gets the mkcert CA private key could issue trusted certs for any domain. For a personal laptop this is fine; for shared machines or CI, prefer explicit per-cert trust.

Why not use a real cert for localhost?

You can't. Let's Encrypt (and every other publicly-trusted CA) refuses to issue certs for localhost, private IP ranges, or any domain they can't validate from the public internet. Self-signed is the only option.

Self-Signed SSL Certificates in Docker

Dima Stopel — Wed, 06 May 2026 12:05:12 +0000

Self-Signed SSL Certificates in Docker

Mount certs, build them into images, or trust them inside a container — all the patterns for self-signed certs in Docker.

Running a self-signed cert in a container is the same as on bare metal — you just need the files where the process can read them. A few patterns cover 99% of use cases.

Pattern 1: Mount certs as a volume (recommended)

Keeps certs out of the image. Rotate them without rebuilding.

# docker-compose.yml
services:
  nginx:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./certs:/etc/nginx/ssl:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro

Then in nginx.conf:

ssl_certificate     /etc/nginx/ssl/certificate.pem;
ssl_certificate_key /etc/nginx/ssl/private-key.pem;

Pattern 2: Docker secrets

For Docker Swarm, put certs in secrets. They're mounted at /run/secrets/ read-only inside the container.

# docker-compose.yml
secrets:
  cert:
    file: ./certificate.pem
  key:
    file: ./private-key.pem

services:
  nginx:
    image: nginx:alpine
    secrets: [cert, key]
    # reference as /run/secrets/cert and /run/secrets/key

Pattern 3: Build certs into the image (dev only)

FROM nginx:alpine
COPY certificate.pem /etc/nginx/ssl/
COPY private-key.pem /etc/nginx/ssl/
COPY nginx.conf /etc/nginx/nginx.conf

Trust a self-signed cert inside the container

If your app runs in a container and needs to call an HTTPS service with a self-signed cert:

# Dockerfile — Debian/Ubuntu-based
COPY ca.pem /usr/local/share/ca-certificates/my-ca.crt
RUN update-ca-certificates

Alpine:

COPY ca.pem /usr/local/share/ca-certificates/my-ca.crt
RUN apk add --no-cache ca-certificates && update-ca-certificates

Pattern 4: Caddy (auto-HTTPS in a container)

For pure local dev, Caddy will generate a self-signed cert on the fly:

# Caddyfile
localhost {
    reverse_proxy app:3000
    tls internal
}

tls internal tells Caddy to mint a cert from its internal CA. Trust Caddy's CA in your OS once, and everything it serves is trusted for the duration of the cert.

Troubleshooting

"SSL_CTX_use_PrivateKey_file failed"

The container can't read the key file. Check volume mount permissions, and make sure the file isn't empty (a common silent failure when a volume path is wrong — it creates an empty directory instead of mounting the file).

Client inside container can't verify a self-signed server

You need to trust the cert inside the container — see the update-ca-certificates pattern above. For Node.js containers, mount the cert and set NODE_EXTRA_CA_CERTS.

Self-Signed SSL Certificate for Apache HTTP Server

Dima Stopel — Wed, 06 May 2026 11:58:36 +0000

Self-Signed SSL Certificate for Apache HTTP Server

Configure Apache to serve HTTPS using a self-signed certificate.

Apache HTTP Server uses mod_ssl for HTTPS. Once the module is enabled, serving a self-signed certificate is just three config directives and a reload.

Step 1: Generate the Certificate

Use cert-depot.com for a browser-friendly cert with Subject Alternative Names, or generate one with OpenSSL:

openssl req -x509 -newkey rsa:2048 -nodes \
  -keyout server.key -out server.crt -days 365 \
  -subj "/CN=example.local" \
  -addext "subjectAltName=DNS:example.local,IP:127.0.0.1"

Step 2: Enable mod_ssl

On Debian/Ubuntu:

sudo a2enmod ssl
sudo a2ensite default-ssl

On RHEL/CentOS, install it if it's not already present:

sudo dnf install mod_ssl

Step 3: Install the Certificate Files

sudo mkdir -p /etc/apache2/ssl  # or /etc/httpd/conf.d/ssl on RHEL
sudo cp server.crt /etc/apache2/ssl/
sudo cp server.key /etc/apache2/ssl/
sudo chmod 600 /etc/apache2/ssl/server.key

Step 4: Configure the VirtualHost

Edit /etc/apache2/sites-available/default-ssl.conf (Debian/Ubuntu) or /etc/httpd/conf.d/ssl.conf (RHEL):

<VirtualHost *:443>
    ServerName example.local
    DocumentRoot /var/www/html

    SSLEngine on
    SSLCertificateFile    /etc/apache2/ssl/server.crt
    SSLCertificateKeyFile /etc/apache2/ssl/server.key

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
</VirtualHost>

Step 5: Test and Reload

sudo apachectl configtest
sudo systemctl reload apache2  # or httpd on RHEL

Verify with curl -kvI https://example.local/ — you should see the TLS handshake succeed and the certificate details.

Troubleshooting

"SSL Library Error: Unable to load private key"

Wrong file permissions or the key is password-protected. Use -nodes when generating with OpenSSL to produce an unencrypted key (safe for development only).

"AH00526: Syntax error"

Run apachectl configtest — it will point to the exact line. Usually a missing closing tag or typo in a file path.

Chrome shows ERR_CERT_COMMON_NAME_INVALID

Your certificate is missing a Subject Alternative Name. Regenerate it with the -addext "subjectAltName=..." flag, or use our generator which includes SANs automatically.

RSA vs ECDSA for Self-Signed Certificates

Dima Stopel — Wed, 06 May 2026 11:57:05 +0000

RSA vs ECDSA for Self-Signed Certificates

Which key algorithm should you pick? Short answer: ECDSA P-256 if everything you're integrating with supports it. RSA 2048 otherwise.

When you generate a self-signed certificate, you pick a key algorithm. Our generator offers RSA 2048, RSA 4096, ECDSA P-256, and ECDSA P-384. Here's how to choose.

Quick Summary

ECDSA P-256 — default for new services. Smaller, faster, cryptographically equivalent to RSA 3072.
RSA 2048 — maximum compatibility. If you don't know what will consume the cert, use this.
RSA 4096 — only if a compliance checklist demands it. Slower, larger, no meaningful security advantage over RSA 3072 for normal use.
ECDSA P-384 — for high-assurance scenarios. Overkill for most self-signed certs.

Speed

ECDSA is dramatically faster for signing. On a modern CPU:

RSA 2048 sign: ~1 ms
RSA 4096 sign: ~6 ms (6x slower)
ECDSA P-256 sign: ~0.04 ms (25x faster than RSA 2048)

For a TLS handshake, this matters on high-traffic servers. For a self-signed cert in development, it's immaterial.

Key Size and Certificate Size

ECDSA keys are tiny compared to RSA:

RSA 2048: public key is ~294 bytes, cert is ~1.2 KB
RSA 4096: public key is ~550 bytes, cert is ~1.8 KB
ECDSA P-256: public key is ~91 bytes, cert is ~700 bytes

Smaller certs = faster TLS handshakes, especially on mobile.

Security Equivalence

NIST publishes equivalent strength tables. Summary:

ECDSA P-256 ≈ RSA 3072 (128-bit security)
ECDSA P-384 ≈ RSA 7680 (192-bit security)
RSA 2048 ≈ 112-bit security (acceptable through ~2030)
RSA 4096 ≈ 140-bit security

Both families resist all currently known classical attacks at these sizes. Both are broken by a sufficiently large quantum computer, which doesn't exist yet.

Compatibility

RSA is universally supported. Every SSL/TLS client ever built speaks RSA.

ECDSA is supported by:

All modern browsers (Chrome, Safari, Firefox, Edge — full support since ~2013)
curl, wget, OpenSSL, GnuTLS, BoringSSL
Go, Rust, Node.js, Python, Java 8+, .NET Core
All recent Linux distributions, macOS 10.9+, Windows 7+

ECDSA is not supported by some very old embedded devices, certain industrial control systems, Java before 7, and some legacy load balancer firmware. If you're integrating with anything in that list, choose RSA.

Practical Recommendations

Local development, modern stack

Use ECDSA P-256. It's faster, smaller, and everything you care about supports it.

Enterprise / legacy integration

Use RSA 2048. You don't know what 20-year-old appliance will encounter the cert; RSA is the safe bet.

Compliance requires 4096+

Use RSA 4096 or ECDSA P-384. The compliance requirement is usually a checkbox, not a cryptographic necessity.

Air-gapped / future-proofing

Neither is quantum-safe. When post-quantum crypto is standardized (ML-DSA etc.), you'll want to regenerate anyway. Don't pick an algorithm based on quantum threats today.

Convert PEM to PFX (PKCS#12) with OpenSSL

Dima Stopel — Wed, 06 May 2026 11:50:35 +0000

Convert PEM to PFX (PKCS#12) with OpenSSL

Bundle your cert and key into a single password-protected PFX file — the format Windows, IIS, and Java expect.

PEM (two files: .crt + .key) is the native format on Linux and most open-source servers. PFX (also called PKCS#12, .pfx, or .p12) bundles both into a single password-protected file — required by IIS, Windows Certificate Store, and Java keystores.

Basic conversion

openssl pkcs12 -export \
  -out certificate.pfx \
  -inkey private-key.pem \
  -in certificate.pem \
  -name "My Certificate"

OpenSSL will prompt for a password. Enter something non-empty — Windows refuses to import PFX files with empty passwords.

Including a CA chain

If your cert has a chain (intermediate CA certs), include them with -certfile:

openssl pkcs12 -export \
  -out certificate.pfx \
  -inkey private-key.pem \
  -in certificate.pem \
  -certfile ca-chain.pem \
  -name "My Certificate"

Scripting (non-interactive)

To avoid the password prompt, pass it via -passout:

openssl pkcs12 -export \
  -out certificate.pfx \
  -inkey private-key.pem \
  -in certificate.pem \
  -password pass:MyPassword123

Skip the conversion entirely

Our generator can output PFX directly. Pick "PFX" as the output format, enter a password, and get a ready-to-import file.

Reverse: PFX to PEM

Extract the certificate:

openssl pkcs12 -in certificate.pfx -clcerts -nokeys -out certificate.pem

Extract the private key (unencrypted — dev only):

openssl pkcs12 -in certificate.pfx -nocerts -nodes -out private-key.pem

Extract the CA chain only:

openssl pkcs12 -in certificate.pfx -cacerts -nokeys -out ca-chain.pem

Modern vs legacy PKCS#12

OpenSSL 3+ uses modern PKCS#12 encryption (AES-256) by default, which some older Windows versions can't read. If IIS or a legacy Windows tool refuses to import your PFX, regenerate with legacy encryption:

openssl pkcs12 -export -legacy \
  -out certificate.pfx \
  -inkey private-key.pem \
  -in certificate.pem

Troubleshooting

"Error unable to get local issuer certificate"

Your cert is signed by a chain your OpenSSL can't resolve. Use -certfile to supply the chain, or use -CAfile /etc/ssl/certs/ca-certificates.crt.

"Mac verify error"

Wrong password when decrypting a PFX. If you don't know the password, there's no recovery — you'll need the original PEM files.

The PFX imports but is "not associated with a private key"

The private key didn't match the certificate's public key. Check with our PEM decoder — if the public key differs from what your key computes, they're not a matching pair.

DEV Community: Dima Stopel

Why Subject Alternative Names (SANs) Matter for Modern Browsers

Why Subject Alternative Names (SANs) Matter for Modern Browsers

The short version

When did this change?

What a SAN looks like

Generating a cert with SANs

Types of SAN you can include

Wildcard rules

Can the CN still be set?

Further Reading

How to Trust a Self-Signed Certificate on Windows

How to Trust a Self-Signed Certificate on Windows

Method 1: Double-click (easiest)

Method 2: PowerShell

Method 3: MMC (full control)

Verify It Worked

Removing the Certificate

Troubleshooting

Cert installs but browser still shows warning

"The parameter is incorrect" during import

Certificate has no SAN

Further Reading

How to Trust a Self-Signed Certificate on macOS

How to Trust a Self-Signed Certificate on macOS

GUI: Keychain Access

Command Line

Verify It Worked

Common Issues

Still getting "certificate not trusted" in Chrome

Certificate has no SAN

The cert imports but stays "Not Trusted"

Further Reading

How to Trust a Self-Signed Certificate in Firefox

How to Trust a Self-Signed Certificate in Firefox

Option 1: Enable OS trust store

Option 2: Import directly into Firefox

Option 3: Import via the warning page

Command line: certutil (for scripting)

Verify it worked

Troubleshooting

Certificate imports but site still shows warning

enterprise_roots doesn't seem to do anything

Cert is trusted but Firefox still complains about SANs

Further Reading

How to Trust a Self-Signed Certificate in Chrome

How to Trust a Self-Signed Certificate in Chrome

Prerequisites

macOS

From the command line

Windows

PowerShell

Linux (Ubuntu/Debian)

Chrome-specific NSS database (Linux only)

Verify It Worked

Further Reading

How Long Should a Self-Signed Certificate Be Valid?

How Long Should a Self-Signed Certificate Be Valid?

The 398-day browser limit

Self-signed certs can be any duration

Practical defaults

Local development on your laptop: 1–5 years

Internal tools / internal CA: 90 days to 1 year

CI/CD or ephemeral test environments: 30–90 days

Certificate authority root (your own internal CA): 10–20 years

What browsers will accept from self-signed sources

Reading the validity period of an existing cert

Further Reading

Self-Signed SSL Certificate for Node.js HTTPS Server

Self-Signed SSL Certificate for Node.js HTTPS Server

Step 1: Generate the Certificate

Native https module

Express

Fastify

Making fetch / axios / node-fetch trust the certificate

PFX / PKCS#12 alternative

Further Reading

Self-Signed Certificates for localhost Development

Self-Signed Certificates for localhost Development

Step 1: Generate the certificate