I recently encountered a frustrating SSL validation scenario where Chrome refused to trust a corporate CA-signed certificate, despite it being properly installed in the system certificate store. Here's my deep dive into solving this issue on Ubuntu 18.04.

The certificate chain displayed by OpenSSL shows:

0 s:/C=REDACTED
   i:/DC=REDACTED/DC=REDACTED/CN=IssuingCA
 1 s:/DC=REDACTED/DC=REDACTED/CN=IssuingCA
   i:/CN=RootCA
 2 s:/CN=RootCA
   i:/CN=RootCA

This three-tier hierarchy indicates we're dealing with a private PKI infrastructure with an intermediate CA.

While adding the root CA to the system store worked for OpenSSL:

sudo su
cp RootCA /usr/local/share/ca-certificates/extra/RootCA.crt
update-ca-certificates

Chrome maintains its own certificate store and doesn't automatically import system certificates on Linux.

Here are three approaches to resolve this:

1. Import Directly into Chrome's NSSDB

Chrome uses NSS (Network Security Services) for certificate management on Linux:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "MyCompany Root CA" -i RootCA.crt

Restart Chrome after executing this command.

2. Use Chrome's Certificate Manager

Manual import through Chrome's interface:

1. Navigate to chrome://settings/certificates
2. Go to "Authorities" tab
3. Click "Import" and select your RootCA.crt
4. Check "Trust this certificate for identifying websites"

3. System-Wide NSS Configuration

For all users on the system:

sudo apt install libnss3-tools
sudo certutil -d sql:/etc/pki/nssdb -A -t "C,," -n "MyCompany Root CA" -i RootCA.crt

Then symlink to make Chrome recognize it:

sudo mkdir -p $HOME/.pki/nssdb
sudo ln -s /etc/pki/nssdb/* $HOME/.pki/nssdb/

After implementation, verify with:

certutil -d sql:$HOME/.pki/nssdb -L

You should see your root CA listed with trust attributes "C,," indicating it's trusted for SSL.

Chrome's security model on Linux differs from other platforms. While it does reference system certificates, it prioritizes its own NSS database for finer-grained control over certificate validation policies.

---

When working with internal services like GitLab that use certificates signed by company CAs, Chrome may still show SSL errors even after adding the root CA to the system trust store. Here's the detailed technical breakdown of why this happens and how to properly configure Chrome to recognize your corporate CA.

Chrome uses multiple certificate stores depending on the platform:

Linux: NSS shared DB (sqlite format)
Windows: Windows Certificate Store
macOS: Keychain

Even though update-ca-certificates updates the system store (typically in /etc/ssl/certs), Chrome on Linux uses its own NSS database.

For complete Chrome trust, you need to:

1. Verify System Trust First

openssl s_client -connect my.git.server:443 -CAfile /etc/ssl/certs/ca-certificates.crt

This should return "Verify return code: 0 (ok)" after adding your CA to the system store.

2. Configure Chrome's Certificate Store

On Linux, use certutil to modify Chrome's NSS DB:

# Install certutil if needed
sudo apt install libnss3-tools

# Find Chrome's cert DB (default locations)
~/.pki/nssdb
~/.config/google-chrome/Default
~/.config/chromium/Default

Then import your CA:

certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n "Company Root CA" -i /path/to/RootCA.crt

Check Chrome's certificate viewer (click the lock icon > Certificate) to verify:

1. The complete certificate chain is visible
2. Each CA in the chain shows as "Trusted"

For advanced debugging, launch Chrome with:

google-chrome --user-data-dir=/tmp/chrome-test --ssl-key-log-file=~/ssl-key.log

For development environments, you can:

1. Add exception in Chrome:

chrome://flags/#allow-insecure-localhost

2. Use certutil for all users:

for dir in /home/*/.pki/nssdb; do
  certutil -d sql:"$dir" -A -t "C,," -n "Company Root CA" -i /path/to/RootCA.crt
done

For enterprise deployments, consider:

• Creating a .deb package that deploys your CA
• Using Group Policy (Windows) or MCX (macOS)
• Setting up proper PKI with intermediate CAs

Remember that Chrome 58+ requires certificates to have proper Subject Alternative Names (SANs) even for internal domains.