Table of Contents:
Error "self signed certificate in certificate chain" or other SSL-related error
When accessing Botium endpoints on servers that don’t have a certificate signed by a globally trusted certification authority, Botium will refuse connection and test cases are failing.
This typically happens when using the Generic HTTP(S)/JSON connector, or a connector derived from it (most custom connectors).
The solution is to tell Botium to ignore SSL specific errors like this.
Now the errors about self-signed certificates should be ignored by Botium.
You can reach the same by adding this environment variable NODE_TLS_REJECT_UNAUTHORIZED to your docker-compose file or your Kubernetes deployment. In this case, it is in effect globally for all chatbot connectors.
Still SSL Error: DEPTH_ZERO_SELF_SIGNED_CERT or other
In case you receive an additional error about DEPTH_ZERO_SELF_SIGNED_CERT or anything else, you have to tell Botium to ignore these errors as well.
Now basically all SSL problems are ignored by Botium.
Git Error 128
When using a remote git repository in Botium Box and it constantly keeps failing with a message containing git error 128, you can try the following:
Verify Git Connectivity
Most likely connection to the Git repository fails for networking reasons. Make sure that your company firewall or your local firewall allows connection to the Git server.
If you require an HTTP(S) proxy, you will have to configure it in the Git settings. As Botium Box is running in Docker containers, you have to add the required configuration in the container itself.
Open a shell to the Botium Box Server or Botium Box Agent containers and run these command:
git config --global http.proxy http://<username>:<password>@<proxy-server-url>:<port>
If you are using a self-signed SSL certificate, or an SSL certificate signed by a non-standard authority, you can disable the SSL verification by adding this line:
git config --global http.sslVerify false
See this article for more configuration examples.
When running a Botium Box update or when recreating the containers, those settings will be lost.
Path name too long
When on Windows and the git repository is nested deeply, it can happen that the path names are too long for the Windows system. What you can do to shorten the path is to modify the BOTIUM_TEMPDIR environment variable to something very short. This is the directory for Botium Box to place temporary files, and Git repositories are checked out there by default.
By default, it points to the botiumwork directory under the installation directory, and depending where you installed it, the total absolute path can get pretty long.
Set it to something like /tmp/botium or C:\Temp\Botium.
Verify Network Connectivity for Botium Agents
Botium Box may experience troubles when connecting the your chatbot.
There are lots of possible reasons for this, which Botium Box cannot solve by itself:
Company firewall rules are prohibiting access to the chatbot endpoint
Hostname resolution is not configured correctly or not accessible to docker containers
Network access is only possible by using a company HTTP(S) proxy
For HTTP(S) chatbot endpoints or HTTP(S) proxies, SSL certificate handling may be a problem (self-signed certificates, non-standard SSL signer, …)
Hostname mapping within a docker network not configured/used correctly
Hints for Connectivity Troubles
Whenever you are receiving error messages in the Botium Box logs like these, we suggest to verify the network connectivity:
hostname not found
invalid SSL certificate
git error 128
To verify connectivity from your Botium Box Server(s) or Agent(s), follow these steps.
Identify Docker Container
Find the docker container id of the Botium Box Server or a Botium Box Agent. Run this docker command to see the running containers and find the container id in the first column of the container in question:
Select the docker container from the second column, the image name, which points to Botium Box Server or Botium Box Agent.
Connect to Docker Container with Terminal
Run this command to spawn a bash shell within the docker container in question - replace <container-id> with the container id from the previous step.
docker exec -it <container-id> /bin/bash
Check Connectivity with Linux Tools
There are several options now to check the connectivity
Check IP Connectivity with ping
First you should try to ping the IP-Address or Hostname
Check Hostname Resolution with nslookup
If you connect by Hostname instead of IP address, you can check hostname resolution
Check IP/Port Connectivity with nc
netcat is a universal tool to (among others) check network connectivity. To check if the connection to a given port on a given host is available, run this command (obviously, replace IP-Adress and port):
nc -zv <ip-address-to-check> <port>
It will immediatly show if connection is possible.
For more usage scenarios with netcat, ask Google.
Check HTTP(S) Connectivity with wget
To check if HTTP(S) connectivity is given, use wget. To do a simple HTTP(S) GET request, try this:
wget is an extremly versatile tool, please consult the manual or Google for more usage scenarios.
Alternative: Check HTTP(S) Connectivity with curl
Run this command to install curl:
apk add curl
To do a simple HTTP(S) GET request, try this:
Fix Connectivity Problems
Sorry, there are no generic instructions available. Please consult your networking or devops administrators.
When "Security Checks" is enabled, all test cases are failing ?
All test cases are failing with a message similar to self signed certificate error
To solve this problem, follow the instructions here