Working With Self-Signed Certificates in Chrome (Walkthrough Edition)

5 min readSep 7, 2021

Self-signed certificates save time and money from purchasing a certificate from a certificate authority (CA). They are very popular in development/test environments. But certificates that are not issued by a CA recognized by Chrome can cause users to see warnings and error pages. In this post, I will show how to make a self-signed trusted in Chrome, I will walk you through the steps with Kyma — an open-source project that provides a Kubernetes cluster for developing cloud-native applications.

Kyma provides a good example for illustration. You will get the error code NET::ERR_CERT_AUTHORITY_INVALID along with the message Your connection is not private when accessing the console URL in Chrome. This is because the domain console.kyma.local is not protected by a CA trusted by Chrome.

The NET::ERR_CERT_AUTHORITY_INVALID error in Chrome

To get Chrome to accept the self-signed SSL certificate, we need to create a wildcard (*.kyma.local) root certificate and import it into the Google Chrome Admin console as a Certificate Authority (CA). We also need to replace the existing certificate/private key stored in Kyma TLS secrets with the ones signed by our CA.

Environment:

Linux: Linux Mint 20.2 Cinnamon (Kernel: 5.11.0–25-generic)
Kubernetes version: 1.16.15
Kyma: Installed from main
Chrome: 92.0.4515.131

Step 1: Becoming your own CA

If you own CA, you are authorized to sign certificate requests for yourself. To become your own CA involves creating a private key (.key) and a Root Certificate Authority certificate (.pem).

Generate an RSA private key of size 2048:

openssl genrsa -des3 -out rootCA.key 2048

Generate a root certificate valid for two years:

openssl req -x509 -new -nodes -key rootCA.key -sha256 -days 730 -out rootCA.pem

To check just created root certificate:

openssl x509 -in rootCA.pem -text -noout

Tip: Alternatively you can use KeyStore Explorer to verify the certificate generated.

Step 2: Creating a certificate request

Next, we need to generate a certificate signing request (CSR).

First, create a private key to be used during the certificate signing process:

openssl genrsa -out tls.key 2048

Use the private key to create a certificate signing request:

openssl req -new -key tls.key -out tls.csr

Create a config file openssl.cnf with a list of domain names associated with the certificate. Edit the domain(s) listed under the [alt_names] section, be sure they match the domain name you want to use.

# Extensions to add to a certificate requestbasicConstraints       = CA:FALSE
authorityKeyIdentifier = keyid:always, issuer:always
keyUsage               = nonRepudiation, digitalSignature, keyEncipherment, dataEncipherment
subjectAltName         = @alt_names[ alt_names ]
DNS.1 = *.kyma.local

Step 3: Signing the certificate request using CA

To sign the CSR using openssl.cnf:

openssl x509 -req \
    -in tls.csr \
    -CA rootCA.pem \
    -CAkey rootCA.key \
    -CAcreateserial \
    -out tls.crt \
    -days 730 \
    -sha256 \
    -extfile openssl.cnf

This will generate a public certificate (tls.crt) signed by our own CA that we can use on the web server later.

To verify that the certificate is built correctly:

openssl verify -CAfile rootCA.pem -verify_hostname console.kyma.local tls.crt

Step 4: Adding CA as trusted to Chrome

Note that with self-signed certificates your browser will warn you that the certificate is not “trusted” because it hasn’t been signed by a certification authority that is in the trust list of your browser. To gain Chrome’s trust, follow the instruction:

Open Chrome settings, select Security > Manage Certificates.
Click the Authorities tab, then click the Import… button. This opens the Certificate Import Wizard. Click Next to get to the File to Import screen.
Click Browse… and select rootCA.pem then click Next.
Check Trust this certificate for identifying websites then click OK to finish the process.

The imported certificate will appear in the list of Authorities.

Step 5: Configuring certificate in web server

After we have validated the certificate, we can use it to replace the existing certificate in the Kyma web server.

Downloading and installing Kyma is very straightforward, you just simply follow the documentation here. Instead of installing directly from running kyma install command, we are going to install it from GitHub.

Clone the repo and locate the file installation/resources/installer-config-local.yaml.tpl. In Kyma, the certificate and its associated key used for TLS are stored in a ConfigMap file in Base64 format.

To convert our certificate and key to Base64:

cat tls.crt | base64 -w0
cat tls.key | base64 -w0

Once it is done, replace both tlsCrt and tlsKey properties with the value above and install Kyma from local sources:

kyma install — source local — src-path <my-sources>

The following message informs that installation is completed successfully.

Kyma is installed in version: 408cb6a6
Kyma installation took:       0 hours 3 minutes
Kyma is running at:           https://192.168.49.2:8443
Kyma console:                 https://console.kyma.local
Kyma admin email:             admin@kyma.cx
Kyma admin password:          ...

Now access the Kyma console URL in Google Chrome, you should see the browser padlock icon in the address bar that indicates a secure connection has been established between the browser and the web server.

Google Chrome — No warnings for our self-signed SSL certificate

Conclusion

A Self-signed certificate offers some advantages when used in internal networks and software development phases. They are free and save time for verification. By getting Chrome to accept a self-signed certificate, we can establish secure browser-to-website connections.