Nov 17, 2023 by Joren Van Hecke | 162 views
If you ever tried to set up a web application on your local machine with a secure connection (using HTTPS), you likely generated self-signed TLS certificates. When you create your own self-signed certificate, or even when the application you're using generates the certificate itself, your operating system (OS) will likely not trust the certificate. Consequently, also your other applications will not trust the certificate.
For instance, when trying to use the OpenStack command line application (which is written in Python) we get the following error when connecting to our OpenStack instance that uses a self-signed certificate:
user@ubuntu:~$ openstack image list Failed to discover available identity versions when contacting https://10.0.0.45:5000. Attempting to parse version from URL. Could not find versioned identity endpoints when attempting to authenticate. Please check that your auth_url is correct. SSL exception connecting to https://10.0.0.45:5000: HTTPSConnectionPool(host='10.0.0.45', port=5000): Max retries exceeded with url: / (Caused by SSLError(SSLCertVerificationError(1, '[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1007)')))
The error tells us that Python could not verify the certificate that was used by our OpenStack instance. The reason for this is that Python only trusts certificates that are signed by a Certificate Authority (CA) which is trusted by the OS. However, we can make the OS trust your certificate, and thereby also using the OpenStack CLI without errors related to the self-signed certificate.
Disclaimer: the following part assumes that you have
sudo privileges on your machine. If not, the commands will not work, and you will have to use other workarounds which depend on your situation. Some examples are provided below.
Various blogs and forum discussions concerning this topic can be found online . However, it is easy to get lost in the specific issues of some forum posts. Therefore we'll explain more in-depth what steps you can take to get rid of the errors caused by the use of non-trusted self-signed certificates.
We will not dive into the theory concerning the chain of trust built upon certificate authorities, but at least you should understand the basic concept. The certificate that your web application provides to your browser or CLI tool may contain a signature. The entity that generated this signature is called a Certificate Authority (CA). The presence of this signature tells the browser that this particular CA understates that the given certificate really belongs to the website that you are browsing. It is up to the browser to decide whether it trusts this statement. The outcome of this decision depends on whether the browser trusts the CA. If the CA's own certificate is known by the browser, because it is present in a set of trusted CA's, then the browser will also trust the certificates that were signed by this CA.
If we want our OS and applications to trust our self-signed certificate, then we need them to trust the CA that signed our certificate. If you generated the certificate yourself, you likely created a CA certificate along the way. If you used another tool for this, or the certificate was generated by the application you're using, then you may find the CA certificate among the generated certificates. The exact location of the certificate depends on the application at hand. In the case of an OpenStack instance that was installed using Kolla Ansible, the certificates will be located in the folder
/etc/kolla/certificates/ and the CA certificate in a subfolder named
We will use the CLI tool
First, you should locate the certificate of the CA that was used to sign the certificate of the web application that you're using. In our case with OpenStack, the CA certificate is located on the OpenStack server at
We create a symlink in the folder
/usr/local/share/ca-certificates/ that points to our certificate:
sudo ln /etc/kolla/certificates/ca/root.crt /usr/local/share/ca-certificates/KollaAnsible_OpenStack_CA.crt -s
Note that we have to use
sudo, since the folder
/usr/ is write-protected. Ensure that you use the
.crt extension for the name of the symlink! If you change the extension, for example to
.pem, the following steps will not work as intended.
To make our OS aware of your newly added CA certificate, run the
update-ca-certificates tool in the terminal:
It should show something similar to the following output:
Updating certificates in /etc/ssl/certs... rehash: warning: skipping ca-certificates.crt,it does not contain exactly one certificate or CRL 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... done.
As we can see, a certificate, i.e. our CA certificate, has been added. You can now go ahead and connect again to the web application with the self-signed certificate. Normally, you should no longer receive errors concerning the verification.
In some circumstances you may not have access to a user with
sudo permissions. In those cases, you will have to use application specific methods for making the application at hand trust your self-signed certificate.
In local development situations you may even consider disabling certificate validation. Be aware, however, that if an attacker can replace the certificate with their own, you will not easily notice, since you will also trust their certificate. Therefore, disabling certificate validation in any context outside local development should not be done.
The OpenStack CLI tool has a
--os-cacert parameter for providing it with your CA certificate :
openstack --os-cacert /etc/kolla/certificates/ca/root.crt
The OpenStack CLI tool can also use the environment variable
OS_CACERT for validating self-signed TLS certificates of the OpenStack instance . You can configure environment variables in various ways.
By putting assigning the environment variable on the same line as the one where the
openstack command is run, the environment variable will only available during execution of this command:
To configure the environment variable during the current terminal session, you can use the
Similarly, we can add this line to our
openrc.sh file (or
admin-openrc.sh, depending on what you named it) with the login credentials used by the OpenStack CLI client. This way, the certificate will always be used when loading these credentials.
Although there should be no need to disable certificate validation if you have the CA certificate used for signing the self-signed certificate of your OpenStack instance, it is possible to disable validation anyway. This is done by running the
openstack command with the
--insecure flag  or by setting the environment variable
OS_INSECURE=1 when using the OpenStack provider for Terraform .
curl you can include the CA certificate with the
--cacert parameter :
curl --cacert /etc/kolla/certificates/ca/root.crt https://10.0.0.45
Certificate validation can be disabled with the
wget you can include the CA certificate with the
--ca-certificate parameter :
wget --ca-certificate /etc/kolla/certificates/ca/root.crt https://10.0.0.45
Certificate validation can be disabled with the
requests library allows for including your CA certificate as the value of the parameter
Certificate validation can be disabled by setting
When using a self-signed TLS certificate, we may bump into errors related to the fact the certificate could not be verified or validated. There are generally two options to cope with this:
wgetand the Python
 T. Paranhos Lima, 'Python - How to make requests to URLs with self-signed certificates'. Accessed: Nov. 17, 2023. [Online]. Available: writeloop.dev/posts/python-requests-to-urls-with-self-signed-certificates
 ‘OpenStack Command Line’, OpenStack. Accessed: Nov. 17, 2023. [Online]. Available: docs.openstack.org/python-openstackclient/latest/cli/man/openstack.html
 ‘Terraform OpenStack Provider’, Terraform. Accessed: Nov. 17, 2023. [Online]. Available: registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs