How to Install SSL Certificate on Chrome Browser?

How to Install / Trust a Root or Intermediate SSL Certificate in Chrome (Step-by-Step)

When a website uses a private CA, internal corporate SSL, or a self-hosted certificate chain, Chrome may show “Your connection is not private”, NET::ERR_CERT_AUTHORITY_INVALID, or Chrome not trusting certificate errors. This happens because Chrome does not automatically trust unknown Certificate Authorities unless they are explicitly added to your operating system’s trust store. Installing or importing the root CA (or intermediate CA) into Chrome is how you make Chrome trust that SSL certificate permanently.

Unlike server-side SSL installation, which secures the website, this step is about client-side trust — telling Chrome “this certificate authority is legitimate, treat this HTTPS connection as trusted.”

Before installing, it’s important to ensure whether you’re dealing with:

• A root CA (the top of the chain)

• An intermediate CA (links the leaf certificate to the root)

• A self-hosted internal CA (for intranet / dev / staging)

• A custom enterprise certificate (VPN / corporate apps)

Once the CA is trusted, Chrome will stop warning you about the certificate and HTTPS will load normally without bypass prompts.

Step-by-Step: Installing a Root/Intermediate Certificate in Chrome (Windows)

1. Press Win + R, type mmc → Enter

2. Go to File > Add/Remove Snap-in

3. Select Certificates → Computer Account → Local Computer

4. Navigate to
   Trusted Root Certification Authorities > Certificates

5. Right-click → All Tasks > Import

6. Select the .crt, .cer, or .pem file

7. Complete the wizard

8. Restart Chrome

If the certificate is an intermediate CA, install it under:
Intermediate Certification Authorities instead.

Once added, Chrome will trust the SSL certificate automatically.

Step-by-Step: Installing a Root/Intermediate Certificate in Chrome (macOS)

On macOS, Chrome reads trust from Keychain Access, but certificates must be trusted manually or Chrome will still reject them.

1. Open Keychain Access

2. Select System (not Login)

3. Drag/drop or Import the .crt / .cer / .pem file

4. Double-click the certificate

5. Expand Trust

6. Set “When using this certificate” → Always Trust

7. Close window (you may be prompted for password)

8. Restart Chrome

After this step, Chrome will recognize the certificate as a trusted authority — which fixes most “Chrome not trusting certificate” issues for internal or self-issued CAs.

How to Install a Client Certificate (.p12 / .pfx) in Chrome (for Authentication / VPN / Enterprise Access)

Some websites don’t just require a trusted SSL certificate — they require the browser to present a client certificate in order to authenticate the user. This is common in corporate networks, VPN gateways, banking portals, enterprise dashboards, government services, and mutual TLS (mTLS) environments. In this case, you are not “trusting” a site — you are installing your own identity certificate so Chrome can authenticate you to the server.

These certificates almost always come in .p12 or .pfx format because they contain both:

• The public certificate, and

• The private key (locked with a password)

Chrome will not use a client certificate unless it is imported into the correct place in the OS trust store.

When you need a client certificate

You are dealing with a client authentication scenario if:

• The site asks for a certificate to log in

• You get a prompt like “Select a certificate to authenticate”

• A VPN requires a .p12/.pfx before connecting

• IT/security provided you with a file and a password

• Chrome shows “This site requires a certificate” instead of a normal login form

Installing a Client Certificate in Chrome (Windows)

1. Double-click the .p12 or .pfx file

2. Windows Certificate Import Wizard opens

3. Choose Current User

4. When asked for location, select Personal certificate store

5. Enter the password for the private key

6. Complete wizard → Finish

7. Restart Chrome

Chrome will now be able to present this certificate to the site when requested.

Installing a Client Certificate in Chrome (macOS)

1. Open Keychain Access

2. Click Login keychain

3. Import or drag/drop the .p12 / .pfx file

4. Enter the password to unlock the private key

5. The certificate will now appear in My Certificates

6. Restart Chrome

Since macOS uses Keychain for identity, Chrome immediately detects the client certificate.

Why Chrome sometimes “does not ask” for the certificate

A very common confusion is when users install the .p12 successfully, but Chrome doesn’t prompt to choose it. This is almost always because:

• The certificate does not match the requested domain (SAN mismatch)

• The certificate chain is not trusted

• The CA was not installed alongside the client certificate

• The site or SNI request differs from what the cert was issued for

Which leads into the third scenario — local development / self-signed environments — where Chrome refuses certificates unless you explicitly mark them as trusted.

How to Trust / Install a Self-Signed SSL Certificate for Localhost in Chrome

Self-signed SSL certificates are common in local development environments (Node.js, Laravel Valet, Docker, React/Next.js, etc.), but Chrome does not trust them by default because they aren’t issued by a recognized Certificate Authority. This leads to NET::ERR_CERT_AUTHORITY_INVALID, even if HTTPS technically works. What most developers miss is that Chrome doesn’t just need the leaf certificate — it needs to trust the root CA that generated it.

Firefox may load the certificate because it has its own browser-level trust store, but Chrome inherits trust from the operating system, not the browser. If the root CA isn’t installed in the OS trust store, Chrome will continue to reject it.

Why localhost HTTPS fails in Chrome

In local development, the leaf localhost certificate is signed by your own dev CA. Unless that root CA is explicitly trusted, Chrome cannot validate the certificate chain. Trusting only the leaf cert fails because Chrome always validates the issuer, not just the end certificate.

The correct solution

The fix is not to “trust localhost.crt” — the correct step is to install and trust the root CA that issued the localhost certificate.

How to trust a self-signed root CA in Chrome (macOS)

1. Open Keychain Access

2. Go to the System keychain (not “Login”)

3. Import the root CA (.crt / .pem)

4. Double-click it → expand Trust

5. Set “When using this certificate” → Always Trust

6. Close Keychain Access and restart Chrome

If you import into the wrong keychain (Login instead of System), Chrome will still show the error.

How to trust a self-signed root CA in Chrome (Windows)

1. Open certmgr.msc (Windows Certificate Manager)

2. Navigate to: Trusted Root Certification Authorities

3. Right-click → Import

4. Select your CA file (.crt / .cer / .pem)

5. Complete the wizard and restart Chrome

Importing into “Personal” or “Intermediate” does not make Chrome trust it — it must go under Trusted Root.

Once the CA is trusted, all certificates issued from it (including localhost) will be considered secure by Chrome — no more browser warnings.

Chrome Certificate Store vs OS Trust Store (How Chrome Decides Which SSL Certificates to Trust)

A common misconception is that Chrome has its own built-in certificate storage like Firefox. In reality, Chrome does not store or manage SSL certificates independently — it mirrors the trust decisions of your operating system. That means when you “install” or “import” an SSL certificate into Chrome, you are really adding it to Windows Certificate Manager (on Windows) or macOS Keychain Access (on Mac). Chrome simply reads those trusted authorities and applies them during HTTPS validation.

This is also why a certificate may work perfectly in Firefox but still show NET::ERR_CERT_AUTHORITY_INVALID or Your connection is not private in Chrome — Firefox uses an internal trust store, so it doesn’t care what Windows/macOS trust. Chrome does.

How Chrome decides whether to trust an SSL certificate

Chrome checks trust in the following order:

1. Is the root or intermediate CA trusted in the OS trust store?
   If not → Chrome blocks it.

2. Does the certificate chain link correctly from leaf → intermediate → root?
   If intermediate is missing → Chrome fails identity validation.

3. Is the hostname covered (CN/SAN)?
   If not → domain mismatch → Chrome refuses.

4. Is the certificate issued by a CA that macOS/Windows recognizes?
   If private CA is missing → Chrome shows untrusted.

Quick comparison: Chrome vs Firefox certificate trust

This difference is exactly why importing a client certificate or self-signed root CA into Keychain or Certificate Manager is required for Chrome — not just dropping the .crt into Firefox.

Now that the trust logic is clear, the next part will cover how to verify certificate installation and fix Chrome when it still doesn’t trust the certificate, especially after importing.

Why Chrome Still Shows “Not Trusted” After Installing the Certificate (And How to Fix It)

Even after you import or install an SSL certificate into Chrome’s trust store, the browser may still display errors like NET::ERR_CERT_AUTHORITY_INVALID, Your connection is not private, or certificate not trusted. This usually leads people to believe the installation “didn’t work” — but in most cases, the issue is not the installation itself, but an incomplete trust chain, an incorrect trust location, or a mismatch between the certificate and the domain Chrome is validating.

Chrome will only trust a certificate if all of the following are true:

1. The root CA is installed in the correct trust store

2. The intermediate CA is also available (or bundled in the fullchain)

3. The hostname (CN/SAN) matches the site

4. The certificate chain is complete and presented during TLS handshake

5. The certificate was installed in the System trust store (macOS) or Trusted Root Certification Authorities (Windows)

If any of these are missing, Chrome continues to treat the connection as untrusted — even if you already imported the .crt or .p12.

The most common reasons Chrome “still doesn’t trust” the certificate

This is why developers often get confused — “I installed it, but Chrome still shows untrusted.” In almost all of these cases, the fix is to install the issuer CA, not the leaf.

Quick Fix Summary

If Chrome still doesn’t trust the certificate:

• Confirm the root CA is installed, not just the certificate itself

• Use System Keychain (macOS) or Trusted Root (Windows)

• Ensure the SAN field includes the domain (especially for localhost)

• Restart Chrome completely after trust changes

• If HTTPS is behind a proxy/CDN, make sure the fullchain is served

Chrome does not “guess” or “fetch” missing intermediate certificates the way Firefox sometimes does — it expects the entire trust chain to be explicitly available.

How to Test if Chrome Now Trusts the SSL Certificate

After installing a root CA, client cert, or self-signed certificate, you should verify that Chrome is actually using it and that the certificate chain is trusted. Testing is important because Chrome may cache previous trust decisions or fallback to an untrusted chain if the intermediate is missing or served incorrectly.

The simplest validation is to open the target HTTPS URL in Chrome, but to be certain the trust chain is working correctly, you should also inspect the certificate path and confirm that Chrome recognizes the issuer.

Step 1: Check the certificate directly in Chrome

1. Open the website or localhost application using HTTPS

2. Click the padlock icon in the address bar

3. Click Connection is secure → Certificate is valid

4. Inspect the “Issued by” section

5. Ensure it shows your trusted CA (not “self-signed” unknown issuer)

If Chrome still shows “certificate not valid” or “issuer not trusted”, the CA was either installed in the wrong trust store or the intermediate certificate is missing.

Step 2: Validate the chain using Developer Tools

1. Open chrome://settings/security and confirm HTTPS is active

2. Open DevTools → Security tab

3. Chrome will display:

   • “Valid and trusted” (correct)

   • OR “Certificate is not trusted” (chain issue)

   • OR “Missing intermediate” (improper install on server/client)

This is especially useful for local development because it shows what Chrome actually doesn’t like about the certificate.

Step 3: Confirm using command-line (optional but accurate)

On macOS/Linux:

On Windows (PowerShell via WSL or Git Bash):

Look for:

• Correct chain order (leaf → intermediate → root)

• “Verify return code: 0 (ok)” at the end

If you see:

then Chrome will also reject it until the intermediate or root CA is fully trusted.

Why Testing Matters

Many developers assume the certificate is installed correctly because they imported a .crt file — but in reality, Chrome will only mark it “trusted” once the full certificate chain is verified. Testing lets you confirm whether the installation succeeded or if an intermediate/root CA step is still missing.

Troubleshooting: When Chrome Still Doesn’t Trust the Certificate After Installation

If Chrome continues to show “Your connection is not private”, NET::ERR_CERT_AUTHORITY_INVALID, or still refuses the self-signed / internal SSL certificate even after you have imported it, the problem is typically not the install process itself — it is that the certificate chain is incomplete, installed in the wrong trust store, or mismatched to the domain Chrome is verifying. Chrome is extremely strict about chain order, SAN fields, and system trust location, so a single missed step will cause it to ignore the certificate.

Before reinstalling anything, walk through these diagnostic checks to find which layer is still blocking trust.

1. Wrong certificate installed (leaf installed instead of root CA)

Many users mistakenly install the final (leaf) certificate instead of the root CA. Chrome checks the issuer, not the leaf.

• Fix → install the root CA (and intermediate if present)

2. Installed in the wrong location (macOS)

Safari and Chrome only trust certificates in System keychain.

• If you imported it into Login keychain → Chrome ignores it

• Fix → move/import to System keychain & set Always Trust

3. Installed in the wrong store (Windows)

On Windows, Chrome ignores certificates placed under Personal.

• Fix → import into Trusted Root Certification Authorities

4. Missing intermediate certificate (common with custom CAs)

Even if the root is installed, the intermediate CA must also be present for Chrome to build the full chain.

• Fix → install both intermediate + root CA

5. SAN mismatch (Chrome rejects CN-only certs)

Chrome 58+ requires SAN (Subject Alternative Name).

• A certificate with only CN=localhost is not enough

• Fix → regenerate self-signed cert with SAN properly configured

6. Chrome caching an old “untrusted” chain

Chrome sometimes caches a prior invalid chain.

• Fix → flush Chrome sockets after updating trust
  chrome://net-internals/#sockets → Flush

7. Proxy/VPN rewriting the certificate

Some corporate or public networks insert their own CA.

• Fix → test over mobile hotspot or offline LAN

• If it works → network MITM was replacing the cert

8. Using Firefox as a false “success signal”

Firefox uses its own trust store, so a cert working in Firefox does not mean Chrome will trust it yet.

• Fix → import the CA into the OS trust store, not Firefox store

If none of the above fixes the trust issue, the certificate likely needs to be regenerated with proper SAN fields and a valid CA chain. That is extremely common in developer localhost setups and internal corporate services.

Prevention & Best Practices (So Chrome Continues to Trust the SSL Certificate)

Once you’ve successfully installed or imported the SSL certificate into Chrome’s trust store, it’s important to prevent the browser from rejecting it again — especially when working with internal systems, enterprise authentication, or localhost development environments. Because Chrome’s trust model is OS-based and certificate-chain sensitive, a small misconfiguration can cause Chrome to suddenly lose trust and show NET::ERR_CERT_AUTHORITY_INVALID, even if everything was working previously.

For Users / IT / Enterprise Environments

When you’re installing a root CA or internal SSL certificate for an intranet or corporate network, the most important rule is consistency across devices. If one workstation trusts the CA but another does not, Chrome will behave differently based on the local trust store.

To prevent identity failures in Chrome:

• Always install the root certificate, not just the leaf certificate

• Keep both root and intermediate CAs bundled correctly

• Distribute certificates via MDM or group policy in enterprise networks

• Use System trust store, not user-only trust store

• Avoid MITM SSL filtering unless the CA is also installed system-wide

For Developers (Localhost / Test / Staging Certificates)

Self-signed and staging certificates break most often when SAN fields are missing or regenerated incorrectly.

To prevent recurring trust errors:

• Always generate certs with Subject Alternative Name (SAN), not just CN

• Trust the root CA that signs localhost, not the leaf certificate

• Use fullchain bundles when testing in containerized or proxied environments

• Avoid regenerating the CA unless you plan to re-import it

• Restart Chrome after every trust-store change

Why prevention matters

Chrome does not “guess” trust — it recreates the certificate chain on every TLS handshake. If the root or intermediate CA is missing, mis-filed, or overwritten, Chrome will immediately fall back to an untrusted state. Maintaining consistency in how certificates are created and installed is what prevents trust failures long-term.

Frequently Asked Questions (FAQ)

1. Can you install an SSL certificate directly in Chrome?

Not exactly. Chrome does not have its own certificate store. When you “install” an SSL certificate in Chrome, you are actually importing it into the operating system trust store (Windows Certificate Manager or macOS Keychain). Chrome simply reads trust from the OS.

2. How do I make Chrome trust a self-signed certificate?

Chrome will only trust a self-signed certificate if you import the root CA that issued it into the system trust store. Importing only the leaf localhost certificate does not work. You must trust the issuer (CA), not the leaf.

3. Why does Chrome still show NET::ERR_CERT_AUTHORITY_INVALID after importing the certificate?

This usually means:

• The certificate was installed in the wrong trust store (Login instead of System)

• The root CA was not imported, only the leaf cert

• The intermediate certificate is missing

• The SAN field does not match the domain

Chrome is more strict about SAN and full trust chain than Firefox or Safari.

4. Where does Chrome store certificates on Windows?

Chrome uses the Windows Certificate Manager, specifically:
Trusted Root Certification Authorities (for root CA)
and
Intermediate Certification Authorities (for intermediate CA)

5. Where does Chrome store certificates on macOS?

Chrome relies on macOS Keychain Access, specifically the System Keychain, not the Login keychain. Certificates in Login keychain are not always honored for HTTPS trust.

6. How do I install a .pfx / .p12 client certificate in Chrome?

You import it into the Personal / My Certificates store (Windows) or Login keychain under “My Certificates” (macOS). A password is required because it contains a private key. This is used for client authentication, not CA trust.

7. Does importing into Firefox also import into Chrome?

No. Firefox has its own trust store, separate from Chrome and the OS. A certificate trusted in Firefox may still show as untrusted in Chrome until added to the OS trust store.

8. Why does Chrome trust some certificates automatically but not others?

Because public CAs (e.g., DigiCert, Sectigo, GlobalSign, Let’s Encrypt) are already in the OS trust store. Private/internal/self-signed CAs are not — and must be installed manually.

Conclusion

Installing an SSL certificate in Chrome is really about adding trust — not just importing a file. Because Chrome does not manage certificates internally, it relies entirely on the operating system trust store (Windows Certificate Manager or macOS Keychain). This is why a certificate may work in Firefox but still show NET::ERR_CERT_AUTHORITY_INVALID in Chrome: unless the root or intermediate CA is trusted at the OS level, Chrome will continue to reject it.

For internal systems, enterprise apps, or corporate networks, this usually means installing a root CA so Chrome trusts the SSL certificate chain. For authentication-based systems, it means importing a client certificate (.p12 / .pfx) so Chrome can present your identity. And for local development, it means trusting the CA that issued your self-signed certificate, not just the localhost certificate itself.

Once the certificate is installed in the correct trust store — and the chain is complete — Chrome will load the HTTPS connection with no warnings, no privacy errors, and full TLS validation.