SSL Certificate Not Trusted on Internal Site – Quick Fix

You're sitting at your desk, trying to hit the internal HR portal or maybe the company wiki. Chrome throws up that big red NET::ERR_CERT_AUTHORITY_INVALID error. Or Firefox shows SEC_ERROR_UNKNOWN_ISSUER. The site loads fine for your coworker down the hall. Sound familiar?

This almost always happens with internal websites using a self-signed certificate or one from an internal Certificate Authority (CA) that your company runs. The error isn't that the certificate is broken. It's that your machine doesn't trust the CA that signed it. Your coworker's machine got the CA installed during onboarding. Yours didn't. Simple as that.

Why This Happens

Public websites use certificates from well-known CAs like Let's Encrypt, DigiCert, or GoDaddy. Every OS and browser already trusts those CAs by default. Internal CAs aren't in that list. Your machine needs the root CA certificate installed in the Trusted Root Certification Authorities store. Without it, your browser sees an orphan certificate and panics.

Don't bother reissuing the certificate on the server. That's not the problem. Fix your client machine's trust store.

The Fix – Step by Step

Step 1: Get the CA Certificate File

You need the root CA certificate file. Usually it's a .cer or .crt file. Ask your IT team or check the internal CA's web interface (like http://your-ca-server/certsrv on a Windows CA). Download the root CA, not the server's certificate. It's typically named something like CompanyRootCA.cer.

Step 2: Install on Windows

1. Right-click the .cer file and choose Install Certificate.
2. Select Local Machine (not Current User). You'll need admin rights.
3. Choose Place all certificates in the following store.
4. Click Browse and pick Trusted Root Certification Authorities.
5. Click OK, then Next, then Finish.
6. Close all browser windows and reopen them.

If you're doing this for multiple machines, use Group Policy or a script. Run this as admin in PowerShell:

Import-Certificate -FilePath "C:\path\to\CompanyRootCA.cer" -CertStoreLocation Cert:\LocalMachine\Root

Step 3: Install on Linux (Ubuntu/Debian)

Copy the .crt file to /usr/local/share/ca-certificates/ and run:

sudo cp CompanyRootCA.crt /usr/local/share/ca-certificates/
sudo update-ca-certificates

On RHEL/Fedora, put it in /etc/pki/ca-trust/source/anchors/ and run update-ca-trust.

Step 4: Firefox – It's Different

Firefox doesn't use the system trust store by default. You have to add the CA manually. Go to Settings > Privacy & Security > scroll to Certificates > click View Certificates > Authorities tab > Import. Pick your .crt file and check the box that says Trust this CA to identify websites.

If you manage many Firefox instances, push the cert via a Mozilla.cfg file or a Group Policy template. It's a headache but necessary.

Step 5: Check the Certificate Chain

Sometimes the server sends only its own cert without the intermediate CA. That can also cause a trust failure even if the root is installed. Open the browser's developer tools (F12), go to the Security tab, and look at the certificate path. You should see the root CA at the top. If the path is incomplete, the server needs fixing, not your client.

Test the chain with OpenSSL from a client machine:

openssl s_client -connect your-internal-site.com:443 -showcerts

Look for verify error:num=20:unable to get local issuer certificate. That means the server isn't sending the full chain.

What to Check If It Still Fails

• Wrong CA file – You might've gotten the server certificate instead of the root CA. The root CA doesn't have a Subject Alternative Name (SAN) for the site.
• Expired CA – Check the validity date on the root CA. Internal CAs expire too. If it's expired, your IT team needs to renew and redistribute it.
• Intermediate CA missing – Some internal setups have a two-tier hierarchy. You need both the intermediate and root CA installed. Ask your PKI admin.
• Browser cache – Hard reload the page with Ctrl+F5 in Chrome or clear the cache. Stale certificate errors can linger.
• VPN or proxy interference – If you're connected to a VPN, it might be stripping or replacing the certificate. Disconnect and test directly on the internal network.

One more thing: if the site uses an IP address instead of a hostname, most browsers will reject any certificate that doesn't match that IP exactly. That's a separate problem – you'll need a certificate with the IP in the SAN field. I've seen teams waste hours on trust store fixes when the real issue was an IP-based URL. Check that first.