Getting Chrome to accept self-signed localhost certificate

Question

I have created a self-signed SSL certificate for the localhost CN. Firefox accepts this certificate after initially complaining about it, as expected. Chrome and IE, however

Answer 1

For a test environment

You can use --ignore-certificate-errors as a command line parameter when launching chrome (Working on Version 28.0.1500.52 on Ubuntu).

This will cause it to ignore the errors and connect without warning. If you already have a version of chrome running, you will need to close this before relaunching from the command line or it will open a new window but ignore the parameters.

I configure Intellij to launch chrome this way when doing debugging, as the test servers never have valid certificates.

I wouldn't recommend normal browsing like this though, as certificate checks are an important security feature, but this may be helpful to some.

Answer 2

For Chrome on MacOS, if you have prepared a certificate:

• Quit Chrome (cmd+Q).
• Start the Keychain Access app and open the "Certificates" category.
• Drag your certificate file onto the Keychain Access window and type the password for the certificate file.
• Double click on your certificate and unfold the "Trust" list.
  • In row "When using this certificate," choose "Always Trust."
  • Close this stuff and type your password.
• Start Chrome and clear all caches.
• Check that everything is ok.

Answer 3

This worked for me. See: http://www.robpeck.com/2010/10/google-chrome-mac-os-x-and-self-signed-ssl-certificates/#.Vcy8_ZNVhBc

In the address bar, click the little lock with the X. This will bring up a small information screen. Click the button that says "Certificate Information."

Click and drag the image to your desktop. It looks like a little certificate.

Double-click it. This will bring up the Keychain Access utility. Enter your password to unlock it.

Be sure you add the certificate to the System keychain, not the login keychain. Click "Always Trust," even though this doesn't seem to do anything.

After it has been added, double-click it. You may have to authenticate again.

Expand the "Trust" section.

"When using this certificate," set to "Always Trust"

Answer 4

For Fedora, Ubuntu, Linux, if you're getting example.com Not a Certification authority error when adding the certificate using the gui to add a new root authority. If you want to trust a server self signed certificate, it cannot make mention of an invalid authority... even if that's itself. I've only managed to make it work by trusting my authority and using that authorities key to sign server certificates.

Here's the self signed CA certificate that it accepted. This is the only way that I found works to get around cert_authority_invalid, I tried for hours to get it to accept a self signed end point certificate, no cigar. The UI will accept self signed authorities, as long as it's declared CA:TRUE. After that, all certs signed by that key with the correct DN will be accepted by chrome without needing to add them independently.

openssl req -new -x509 -extensions v3_req -days 8440 -config ca.conf -key rockstor.key -out rockstor.cert

[req]
distinguished_name=dn
req_extensions=v3_req
prompt = no

[v3_req]
basicConstraints=CA:TRUE,pathlen:0
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName=@alt_names

[alt_names]
DNS.1 = ca.tdpowerskills.com

[dn]
C = US
ST = LA
L = Alexandria
O = TDPS Certification Authority
OU = LEARNOPS
CN = ca.tdpowerskills.com

openssl req -new -x509 -extensions v3_req -days 8440 -config config.conf -key rockstor.key -out rockstor.cert

[req]
distinguished_name=dn
req_extensions=v3_req
prompt = no

[v3_req]
basicConstraints=CA:FALSE
keyUsage = keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName=@alt_names
issuerAltName=DNS:ca.tdpowerskills.com

[alt_names]
DNS.1 = big.tdps.app

[dn]
C = US
ST = LA
L = Alexandria
O = TDPS Certification Authority
OU = LEARNOPS
CN = ca.tdpowerskills.com

If that doesn't work:

• chrome://restart to actually restart

• Try to get more details on the error using firefox, it tends to explain errors better... while chrome will say, ERR_CERTIFICATE_INVALID, firefox will throw: MOZILLA_PKIX_ERROR_CA_CERT_USED_AS_END_ENTITY.

• Remember that chrome now requires Subject Alternate Name and nearly ignores CN.

For others:

• certutil -d sql:$HOME/.pki/nssdb -A -t "P,," -n <nickname> -i <my.crt> // For server sertificates

• certutil -d sql:$HOME/.pki/nssdb -A -t "C,," -n <nickname> -i <my.crt> for CA's https://blogs.oracle.com/meena/about-trust-flags-of-certificates-in-nss-database-that-can-be-modified-by-certutil

• For Firefox, the UI adding an exception certificate does work and it will trust it once you do that.

• Perhaps you have funky settings in /etc/pki/tls/openssl.cnf which get merged with your config.

• perhaps you're no adding an extension to the config or command line, such as v3_req

• Note, my method bypasses the need for a CSR by just signing the certificates with the authority key and adding details for the dev servers. CSR's allow more keys for actual security.

• I tried everything, but chrome requires an authority with basicconstraints CA:true set. And server certificates must all be singed by a valid Authority... even if that's just another certificate that the signed themselves with CA:true.

Answer 5

UPDATED Apr 23/2020

Recommended by the Chromium Team

https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins#TOC-Testing-Powerful-Features

Quick Super-Easy Solution

There is a secret bypass phrase that can be typed into the error page to have Chrome proceed despite the security error: thisisunsafe (in earlier versions of Chrome, type badidea, and even earlier, danger). DO NOT USE THIS UNLESS YOU UNDERSTAND EXACTLY WHY YOU NEED IT!

Source:

https://chromium.googlesource.com/chromium/src/+/d8fc089b62cd4f8d907acff6fb3f5ff58f168697%5E%21/

(NOTE that window.atob('dGhpc2lzdW5zYWZl') resolves to thisisunsafe)

The latest version of the source is @ https://chromium.googlesource.com/chromium/src/+/refs/heads/master/components/security_interstitials/core/browser/resources/interstitial_large.js and the window.atob function can be executed in a JS console.

For background about why the Chrome team changed the bypass phrase (the first time):

https://bugs.chromium.org/p/chromium/issues/detail?id=581189

If all else fails (Solution #1)

For quick one-offs if the "Proceed Anyway" option is not available, nor the bypass phrase is working, this hack works well:

1. Allow certificate errors from localhost by enabling this flag (note Chrome needs a restart after changing the flag value):

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

   (and vote-up answer https://stackoverflow.com/a/31900210/430128 by @Chris)

2. If the site you want to connect to is localhost, you're done. Otherwise, setup a TCP tunnel to listen on port 8090 locally and connect to broken-remote-site.com on port 443, ensure you have socat installed and run something like this in a terminal window:

   socat tcp-listen:8090,reuseaddr,fork tcp:broken-remote-site.com:443

3. Go to https://localhost:8090 in your browser.

If all else fails (Solution #2)

Similar to "If all else fails (Solution #1)", here we configure a proxy to our local service using ngrok. Because you can either access ngrok http tunnels via TLS (in which case it is terminated by ngrok with a valid certificate), or via a non-TLS endpoint, the browser will not complain about invalid certificates.

Download and install ngrok and then expose it via ngrok.io:

ngrok http https://localhost

ngrok will start up and provide you a host name which you can connect to, and all requests will be tunneled back to your local machine.

Answer 6

I tried everything and what made it work: When importing, select the right category, namely Trusted Root Certificate Authorities:

(sorry it's German, but just follow the image)