How to Get Your Own Certificate for a Local Server

Running a local server — whether for development, home automation, a self-hosted app, or an internal business tool — eventually runs into the same wall: your browser flags it as "Not Secure," APIs refuse to connect, and modern web features won't load without HTTPS. Getting your own certificate for a local server solves all of this, but the right approach depends heavily on what you're running and why.

Why Local Servers Need Certificates

Browsers and operating systems use TLS certificates (often called SSL certificates) to verify two things: that a server is who it claims to be, and that traffic between your device and that server is encrypted. Public websites get certificates from trusted Certificate Authorities (CAs) — organizations like Let's Encrypt, DigiCert, or Sectigo that browsers trust by default.

Local servers are different. They typically don't have a public domain name, they don't live on the open internet, and public CAs won't issue certificates for addresses like localhost, 192.168.1.x, or internal hostnames like mydevserver.local. So you have to create your own trust chain — or use a tool that does it for you.

The Three Main Approaches

1. Self-Signed Certificates

A self-signed certificate is one you generate yourself, where you are also the issuing authority. Tools like OpenSSL can create one in a single terminal command:

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 365 -nodes 

This gives you a valid certificate that encrypts traffic — but no browser or OS will trust it by default. You'll see security warnings unless you manually install and trust the certificate on every device that needs to connect.

Best suited for: Quick local testing on a single machine where you control the browser and can dismiss or bypass warnings.

The catch: Every browser and OS has to be configured individually. Mobile devices and some APIs will outright refuse connections with untrusted self-signed certificates, which can block entire categories of testing.

2. A Local Certificate Authority (CA)

This is the more robust approach. Instead of generating a single self-signed cert, you create your own root CA — a private certificate authority that only exists on your network — and then issue certificates signed by that root.

Once you install your root CA's certificate into your operating system's trust store (and your browser's, if it uses a separate one), every certificate you issue from that root will be automatically trusted on that machine. You only do the trust-installation step once per device.

mkcert is a widely used tool that automates almost all of this:

mkcert -install mkcert myapp.local localhost 127.0.0.1 

The first command creates and installs a local root CA. The second generates a trusted certificate for whatever names or IP addresses you specify. Browsers on that machine will treat your local server like a legitimate HTTPS site — no warnings. 🔒

Best suited for: Developers running multiple local projects, teams sharing an internal server, or anyone who needs clean HTTPS without constant browser warnings.

The variable: You still need to manually install the root CA certificate on any other device that needs to trust your local server — phones, tablets, other team members' laptops.

3. Real Certificates for Local-ish Setups

If your local server has a real domain name pointing to it (even one that resolves only inside your network), some options open up:

• Let's Encrypt with DNS challenge: Let's Encrypt can issue a certificate for your domain without your server being publicly reachable, as long as you can prove domain ownership via a DNS TXT record. You never need to expose port 80 or 443 to the internet.
• Wildcard certificates: If you own a domain (e.g., example.com), you can get a wildcard cert (*.example.com) and use subdomains like dev.example.com that resolve internally to your local server.

This approach gives you a certificate issued by a globally trusted CA — no manual trust installation needed on any device.

Best suited for: Homelab setups, internal company tools, or developers who already own a domain and want zero-friction HTTPS across all devices including phones.

The variable: You need a real domain, control over its DNS, and either a compatible DNS provider for automation or the willingness to do manual DNS challenges on renewal.

Key Factors That Change Which Path Makes Sense

What "Trusted" Actually Means Across Different Systems

One point that trips people up: trust stores are not universal. Windows, macOS, Linux, iOS, and Android each maintain their own certificate trust stores, and some browsers (notably Firefox) maintain a separate one independent of the OS.

When you install a root CA or a self-signed cert, you need to install it in the right store for the right application. A certificate trusted by Chrome on macOS may not be trusted by Firefox on the same machine, or by your iPhone on the same Wi-Fi network. 🔐

This is especially relevant for:

• Testing progressive web apps or service workers (require valid HTTPS)
• Mobile browser testing
• Connecting IoT devices or smart home systems to a local server
• Any application that does strict certificate validation

The Part Only You Can Answer

The gap between "I understand how local certificates work" and "I know which approach is right for me" comes down to specifics that vary significantly from one setup to the next. A solo developer running a quick React app on localhost has a very different situation from someone hosting a self-managed Home Assistant instance accessed from phones, tablets, and a smart TV. Both need certificates; neither needs the same solution. Your OS environment, the devices involved, whether you own a domain, and how much you want to maintain over time all push the answer in different directions. 🛠️