How to Configure HTTPS Certificate to Avoid “Untrusted Certificate” Error

If you’ve ever loaded a webpage—or your own local server—and seen the jarring message “Your connection is not private” or “Untrusted Certificate,” you know how annoying it can be. This error typically means your browser doesn’t trust the security certificate presented by the server. The good news is that this is a protective measure, not necessarily a hack, and it is almost always fixable with the right configuration.

Why Does This Happen?

Before diving into the fixes, it helps to understand why your browser is complaining. Generally, browsers only trust certificates that meet four strict criteria:

• They are issued by a recognized Certificate Authority (CA).
• They are not expired.
• They match the specific domain name exactly (e.g., example.com vs www.example.com).
• They are installed with the full certificate chain (intermediate certificates).

If any one of these is missing, the “Untrusted” warning appears.

Step 1: Choose the Right Solution

The fix depends entirely on where this error is happening. Choose the scenario that matches yours:

Scenario A: Public Website (Accessible via Internet)

If this is a website anyone can visit (like a blog or store), you need a recognized certificate.

• Best Fix: Use Let’s Encrypt. It’s free, automated, and trusted by every major browser.
• Alternative: Buy a commercial certificate from DigiCert, Sectigo, or GlobalSign (usually for enterprise needs).

Scenario B: Local Network (NAS, Home Lab, Internal Tools)

If this is a service only you access at home (like 192.168.0.170 or nas.local), standard public certificates won’t work easily strictly on IPs.

• Best Fix (Development): Use mkcert. It creates a locally trusted certificate authority on your machine.
• Best Fix (Production/Home Lab): Use a real domain with DNS Validation via Let’s Encrypt.

Step 2: How to Fix It

Method 1: The “Public Website” Fix (Let’s Encrypt)

This is the standard for 90% of websites. We will use a tool called Certbot.

Install Certbot:
On Ubuntu, type: sudo apt install certbot python3-certbot-nginx

Generate the Certificate:
Run: sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

Follow the prompts: Certbot will verify you own the domain, generate the files, and even update your web server config automatically.
(Note: Certificates renew every 90 days. You can test auto-renewal by running sudo certbot renew --dry-run).

Method 2: The “Home Lab / Local” Fix (mkcert)

If you just want that green padlock on your local development machine or NAS without buying a domain, mkcert is the easiest route.

Install mkcert:
(Mac/Linux) Run brew install mkcert.

Create a Local CA:
Run mkcert -install. This tells your computer to trust certificates created by this tool.

Generate the Certificate:
Run mkcert nas.local 192.168.0.170.

Install the files: Take the resulting .pem and -key.pem files and add them to your Nginx or Caddy configuration.

Step 3: Fix the “Chain of Trust” (Common Nginx/Apache Issue)

Sometimes you have a valid certificate, but the error persists on mobile devices or specific browsers. This usually means you are missing the Intermediate Certificate.

When you download SSL files, you often get a generic certificate and a “bundle” or “chain” file. You must use the combined file.

For Nginx Users

Don’t point to the basic certificate file. Point to the “Full Chain” file.

Incorrect: ssl_certificate /path/cert.pem;
Correct: ssl_certificate /path/fullchain.pem;

For Apache Users

Apache often handles this separately in the config:

SSLCertificateFile /path/to/your_domain.crt
SSLCertificateKeyFile /path/to/your_private.key
Crucial Step: SSLCertificateChainFile /path/to/CA_bundle.crt

Step 4: Check for “Mixed Content”

If you see a grey padlock or a warning that says “Parts of this page are not secure,” check your HTML code.

This happens when your site loads over HTTPS, but images or scripts are loading over HTTP.

• Open Developer Tools: Press F12 → Console tab.
• Look for Red Warnings: It will list exactly which images are loading via HTTP.
• The Fix: Change your links to relative paths (e.g., /images/logo.png) or update them to https://.

What NOT to Do

• Don’t rely on self-signed certificates for public sites. While easy to make, they train users to ignore security warnings, which is a bad habit.
• Don’t ignore expiration dates. Set a calendar reminder if you aren’t using auto-renewal. An expired cert looks just as bad as a missing one.
• Don’t forget the subdomain. A certificate for example.com often covers only that. It does not automatically cover mail.example.com unless you get a “Wildcard” certificate.

Conclusion

Configuring HTTPS doesn’t have to be a headache. The “Untrusted” error is simply the browser’s way of saying the chain of trust is broken. To fix it permanently, start by using Let’s Encrypt for public sites or mkcert for local tools, and always ensure you are referencing the fullchain.pem file in your server configuration.