Self-Signed vs CA-Signed SSL: Private, Internal and Local Certificates

Self signed SSL certificates are certificates signed by their own private key instead of by a certificate authority (CA). They encrypt traffic just as well as CA-signed certificates, but browsers and operating systems do not trust them, so every visitor sees a security warning. Use them for testing and closed systems; use a CA-signed certificate for anything public.

The choice is rarely “self-signed or nothing.” You have three realistic options: a self-signed certificate, a private CA you control, or a publicly trusted certificate from a CA.

Option	Trusted by default?	Works for internal names / private IPs?	Best for
Self-signed certificate	No – warning everywhere	Yes	Quick tests, one-off lab devices
Private CA (your own root)	Only on devices where you install the root	Yes	Intranets, homelabs, managed company devices
Public CA-signed certificate	Yes – all browsers	No (public domains and, with some products, public IPs only)	Websites, APIs, anything outside your control

What is a self-signed SSL certificate?

A self-signed SSL certificate is an X.509 certificate whose issuer and subject are the same, signed with its own private key. No third party has checked who created it, so clients have no reason to trust it.

A CA-signed certificate works differently. A public CA verifies that you control the domain (and, for OV/EV, your organization), then signs your certificate with a key that chains to a root already in every browser’s trust store. That chain of signatures is what removes the warning.

Self-signed SSL certificate vulnerability: why warnings matter

The encryption of a self-signed certificate is not weaker. The risk is that clients cannot tell your certificate from an attacker’s. When users learn to click through warnings, a man-in-the-middle (an attacker who intercepts traffic between client and server) can present their own self-signed certificate and nobody notices. The same risk appears in code that skips validation – read about the risks of disabling SSL verification before you add an “ignore certificate” flag.

Should I use a self-signed certificate for an internal server?

Only if very few people use it and you can install the certificate on their devices. For anything wider, run a private CA or use a public certificate for an internal hostname under a domain you own.

• Self-signed: fine for a single admin panel, a test VM or a device only you open.
• Private CA: create one root, install it once on managed devices (for example via group policy or MDM), then issue as many internal certificates as you need without warnings.
• Public certificate for an internal FQDN: if the server uses a name such as intranet.example.com on a public domain you own, a public CA can issue for it, even if the server is reachable only inside your network. A domain validated (DV) SSL certificate with DNS-based validation is enough.

Tip: For intranet SSL certificates, the third option is often the simplest. Use a real subdomain of your public domain, resolve it internally with split DNS, and validate it with a DNS TXT record – no root to distribute.

Can I get an SSL certificate for an internal hostname like server.local?

No. Since 2015, publicly trusted CAs do not issue certificates for internal names such as server.local, intranet or mail.corp, because nobody can prove unique ownership of them. You need a private CA, a self-signed certificate or a rename to a public domain.

SSL certificates for internal server names therefore come down to these choices:

1. Rename the host to a subdomain of a domain you own (for example nas.home.example.com) and buy a public certificate.
2. Keep the internal name and issue from your own private CA.
3. Keep the internal name and use a self-signed certificate on a handful of trusted devices.

For local SSL certificates in your homelab, the reserved name home.arpa (RFC 8375) is a cleaner choice than .local, which is reserved for multicast DNS and can cause name-resolution conflicts.

Can I get a publicly trusted SSL certificate for an IP address?

For a public IP address, yes – some CAs issue certificates that list a public IP, usually as OV products. For a private IP address such as 192.168.1.10 or 10.0.0.5, no public CA will issue one.

Address type	Public CA certificate?	What to use
Public IPv4/IPv6 you control	Yes, with selected products	An OV product that supports IP addresses – check the product page
Private IP (RFC 1918 ranges)	No	Private CA or self-signed, with the IP in the SAN
Reserved / loopback (127.0.0.1)	No	Self-signed or a local development CA

An SSL certificate for a private IP address must carry the address in the Subject Alternative Name (SAN) field as an IP entry. Modern browsers ignore the Common Name, so a certificate without a matching SAN fails even if you trust the root.

Create a self-signed SSL certificate with OpenSSL

This command creates a 2048-bit RSA key and a self-signed certificate valid for one year, with both a hostname and a private IP in the SAN:

openssl req -x509 -newkey rsa:2048 -nodes -sha256 -days 365 \
  -keyout server.key -out server.crt \
  -subj "/CN=nas.home.arpa" \
  -addext "subjectAltName=DNS:nas.home.arpa,IP:192.168.1.10"

-x509 outputs a certificate instead of a request, and -nodes leaves the key unencrypted so the server can start unattended (OpenSSL 3 also accepts -noenc). Check the result with:

openssl x509 -in server.crt -noout -text | grep -A1 "Subject Alternative Name"

This works the same way to create a self-signed SSL certificate for a home server, a NAS or a Raspberry Pi.

Private SSL certificates from your own CA

If you have more than two or three internal services, a small private CA saves work: you trust one root on each device, and every certificate it signs is accepted. In bash, the three steps look like this:

# 1. Create the private root CA (keep ca.key offline)
openssl req -x509 -newkey rsa:3072 -nodes -sha256 -days 3650 \
  -keyout ca.key -out ca.crt -subj "/CN=Home Lab Root CA"

# 2. Create a key and CSR for the server
openssl req -new -newkey rsa:2048 -nodes \
  -keyout nas.key -out nas.csr -subj "/CN=nas.home.arpa"

# 3. Sign the CSR with your CA, adding the SAN
openssl x509 -req -in nas.csr -CA ca.crt -CAkey ca.key -CAcreateserial \
  -out nas.crt -days 365 -sha256 \
  -extfile <(printf "subjectAltName=DNS:nas.home.arpa,IP:192.168.1.10")

Then import ca.crt – never ca.key – into the trust store of each device. Anyone who gets ca.key can issue certificates your devices will trust, so protect it like a password vault.

How to generate a private key for an SSL certificate

Generate the key on the server that will use it, and never send it to anyone – including your CA. Use RSA 2048 or ECC P-256:

# RSA 2048
openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out private.key

# ECC P-256
openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out private.key

chmod 600 private.key

For a CA-signed certificate, you create a certificate signing request (CSR) from this key and send only the CSR. Our CSR generator builds the matching OpenSSL command for you.

“SSL certificate private key missing” – what now?

A certificate is useless without the private key that matches it. If the key is lost, you cannot recover it: generate a new key and CSR, then reissue the certificate (free during your plan term). On Windows, the error usually means the certificate was imported on a different machine than the one that created the request.

Private key for a wildcard SSL certificate

A wildcard certificate is often installed on several servers, so its private key is copied too. Each copy is a place it can leak. Limit the servers that hold it, store it with strict permissions and reissue with a new key if any server is compromised.