Create a Custom Root Certificate Authority for Self-Signed Certificates

When running multiple services in a local network-whether for smart home automation, home labs or development environments-HTTPS encryption becomes essential. Instead of accepting browser warnings for every self-signed certificate, creating your own Root Certificate Authority (Root CA) provides a clean, professional solution.

What is a Root Certificate Authority?

A Root Certificate Authority is the top-level entity in a Public Key Infrastructure (PKI) that issues and signs digital certificates. When a Root CA certificate is installed as trusted on a device, all certificates signed by that CA are automatically trusted without warnings.

In the public internet, organizations like DigiCert, Let’s Encrypt and GlobalSign operate as Root CAs. Their root certificates come pre-installed in browsers and operating systems worldwide. For a private network, you can create your own Root CA to achieve the same trust model-but only within devices you control.

The certificate chain works like this:

1. Root CA signs server certificates
2. Server presents its certificate to clients (browsers, apps)
3. Client verifies the signature using the trusted Root CA
4. If valid, connection is established with full HTTPS encryption

Why Create Your Own Root CA?

One-Time Trust Setup: Install the Root CA certificate once on each device and all future certificates you issue are automatically trusted-no more “NET::ERR_CERT_AUTHORITY_INVALID” warnings.

Custom Local Domains: Use meaningful domain names like homeassistant.abt, nas.abt or gitlab.lab instead of IP addresses.

Smart Home & IoT Requirements: Many smart home platforms and IoT devices require HTTPS for webhooks, APIs and secure communication.

Development & Testing: Test HTTPS-only features (service workers, secure contexts, WebRTC) in local environments without complicated workarounds.

Full Control: Manage certificate lifecycle, expiration and revocation on your own terms.

No External Dependencies: No reliance on public CAs or internet connectivity for certificate issuance.

My Use Case

I run multiple services in my local network using the .abt top-level domain:

• Home Assistant (homeassistant.abt) – Smart home automation platform
• NAS (nas.abt) – Network storage with web interface
• Bitwarden (vault.abt) – Password manager
• Raspberry Pi projects (*.pi.abt) – Various IoT experiments
• Docker services – Self-hosted applications with web UIs
• Development servers – Local testing with HTTPS requirements
• IoT Devices (*.garden.abt) - Various Internet of Things devices requiring secure communication

All these services must be accessible from Windows PCs, Linux machines, macOS laptops, iPhones and Android tablets with full HTTPS support and no certificate warnings.

Creating the Root CA

Before starting, ensure you have:

• OpenSSL installed on your system
  • Windows: choco install openssl (via Chocolatey)
  • macOS: brew install openssl (via Homebrew)
  • Linux: Usually pre-installed or apt install openssl / dnf install openssl
• Administrator/root access to install certificates on devices
• A secure location to store the CA private key (this is critical!)

Step 1: Create the Directory Structure

First, create a dedicated directory for your CA files:

New-Item -ItemType Directory -Path ".\abt-ca" -Force

Step 2: Create the OpenSSL Configuration File

Create a file abt-ca/abt-ca.cnf with the following content. This configuration defines the Root CA properties:

 1[ req ]
 2default_bits = 4096
 3prompt = no
 4default_md = sha256
 5x509_extensions = v3_ca
 6distinguished_name = dn
 7
 8[ dn ]
 9C  = DE
10O  = ABT
11CN = ABT Private Root CA
12
13[ v3_ca ]
14subjectKeyIdentifier = hash
15authorityKeyIdentifier = keyid:always
16basicConstraints = critical, CA:true
17keyUsage = critical, keyCertSign, cRLSign

Configuration breakdown:

• default_bits = 4096: Strong 4096-bit RSA key
• default_md = sha256: SHA-256 hashing algorithm
• x509_extensions = v3_ca: Apply CA-specific extensions
• basicConstraints = critical, CA:true: Mark as a Certificate Authority
• keyUsage = critical, keyCertSign, cRLSign: Allow certificate signing and CRL signing

Distinguished Name fields:

• C: Country code (DE for Germany, US for United States, etc.)
• O: Organization name (your name, network name, etc.)
• CN: Common Name-what users see when viewing the certificate

Step 3: Generate the Root CA Private Key

Create the private key for your Root CA. This is the most sensitive file in your entire PKI-protect it accordingly:

openssl genrsa -out abt-ca/abt-ca.key 4096

This generates a 4096-bit RSA private key without a passphrase. If you want additional security (recommended for production-like environments), add -aes256 for encryption:

openssl genrsa -aes256 -out abt-ca/abt-ca.key 4096

You’ll be prompted for a passphrase every time you use the key to sign certificates.

Step 4: Create the Root CA Certificate

Now generate the self-signed Root CA certificate using the private key and configuration file:

openssl req -x509 -new -key abt-ca/abt-ca.key -sha256 -days 3650 -out abt-ca/abt-ca.pem -config abt-ca/abt-ca.cnf

Command breakdown:

• -x509: Create a self-signed certificate
• -new: Generate a new certificate request
• -key abt-ca/abt-ca.key: Use the private key from Step 3
• -sha256: Use SHA-256 signature algorithm
• -days 3650: Certificate valid for 10 years (adjust as needed)
• -out abt-ca/abt-ca.pem: Output certificate in PEM format
• -config abt-ca/abt-ca.cnf: Use the configuration file from Step 2

Step 5: Verify the Root CA Certificate

Confirm the certificate was created correctly and has proper CA attributes:

openssl x509 -in "abt-ca/abt-ca.pem" -noout -text | Select-String -Pattern "Basic Constraints" -Context 0,3

Expected output:

1X509v3 Basic Constraints: critical
2    CA:TRUE
3X509v3 Key Usage: critical
4    Certificate Sign, CRL Sign

If you see CA:TRUE and the key usage includes Certificate Sign, CRL Sign, your Root CA is correctly configured.

You can also view the full certificate details:

openssl x509 -in abt-ca/abt-ca.pem -noout -text

Step 6: Create DER Format (for Some Devices)

Some platforms (especially mobile devices) prefer DER format instead of PEM. Create a DER version of your Root CA certificate:

openssl x509 -in .\abt-ca\abt-ca.pem -outform der -out .\abt-ca\abt-ca.der

You now have:

• abt-ca.key – Private key (keep secure!)
• abt-ca.pem – Root CA certificate (PEM format)
• abt-ca.der – Root CA certificate (DER format)
• abt-ca.cnf – OpenSSL configuration

Installing the Root CA on Devices

For certificates to be trusted, install the Root CA certificate on all your devices. Use abt-ca.pem for most systems, abt-ca.der for mobile devices.

Windows

1. Double-click abt-ca.pem (or abt-ca.der)
2. Click “Install Certificate”
3. Select “Local Machine” (requires Administrator)
4. Choose “Place all certificates in the following store”
5. Click “Browse” and select “Trusted Root Certification Authorities”
6. Complete the wizard

iOS/iPadOS

1. Transfer abt-ca.der to your device (email, AirDrop or host on a web server)
2. Open the .der file-you’ll see “Profile Downloaded”
3. Go to Settings → General → VPN & Device Management
4. Under “Downloaded Profile”, tap “ABT Private Root CA”
5. Tap “Install” and enter your passcode
6. Tap “Install” again to confirm
7. Go to Settings → General → About → Certificate Trust Settings
8. Enable full trust for “ABT Private Root CA”

Double check, if the custom CA is enabled! Otherwise you will still get warnings.

Security Considerations

Protect the Private Key: The Root CA private key (abt-ca.key) is the most critical file. Anyone with access can issue trusted certificates for any domain. Store it encrypted, offline and with strict access controls.

Limited Distribution: Only install the Root CA on devices you own and control. Never distribute it publicly or to untrusted parties.

Scope of Trust: This Root CA should only be used for your private network. Don’t use it to sign certificates for public internet domains.

Backup Strategy: Keep encrypted backups of your CA files in multiple secure locations (password manager, encrypted USB drive, secure cloud storage).

Certificate Expiration: Monitor server certificate expiration dates. Set reminders to renew before expiry.

Key Length: Use 4096-bit keys for the Root CA, 2048-bit minimum for server certificates.

Revocation: In production environments, implement Certificate Revocation Lists (CRL) or OCSP. For home use, manually replacing compromised certificates is usually sufficient.

Common Pitfalls

“This site is not secure” – Root CA not installed on the device or certificate Common Name/SAN doesn’t match the URL.

DNS doesn’t resolve – Certificate is valid, but the domain doesn’t resolve. Configure local DNS (router, Pi-hole, /etc/hosts) to point .abt domains to correct IPs.

Mixed content warnings – HTTPS page loading HTTP resources. Ensure all assets use HTTPS or relative URLs.

Hostname mismatch – Accessing https://192.168.1.100 won’t work if the certificate is for homeassistant.abt. Use the domain name or add the IP to Subject Alternative Name.

Certificate expired – Server certificates expire before the Root CA. Keep track of expiration dates.

Mobile apps don’t trust the CA – Android 7+ and iOS restrict user-installed CAs for some apps. Use system-level installation methods or accept limitations.

Lessons Learned

• Separate Root CA and server operations: Keep the Root CA key offline. Only bring it online when signing new certificates.
• Document everything: Maintain a spreadsheet or certificate management database with issuance dates, domains and expiration dates.
• Use Subject Alternative Names (SAN): Always include SAN entries, even for single-domain certificates. Some browsers require it.
• Plan for renewal: Server certificates have shorter lifespans. Automate renewal reminders or use scripts for bulk reissuance.
• Reverse proxies simplify management: Use nginx or Traefik as a reverse proxy for multiple services. Manage HTTPS in one place instead of configuring every service individually.
• Test on all platforms: Verify certificate trust on Windows, macOS, Linux, iOS and Android before relying on it.

Good luck with your private certificate infrastructure!