In today’s digital age, security has become a top priority for businesses of all sizes. With the increasing number of cyber-attacks and data breaches, ensuring that your website and applications are secure is essential. Usually, access to websites that are actively being developed or are intended for private/internal usage within an organization is restricted. A common way to do this is with custom SSL certificates. This ensures that the website won’t be publicly available.
In Loadero we allow saving SSL certificates and they will be set up for the browser when a test participant executes your script. As of writing this blog post, this can only be done in Loadero, using our API. We value our customers’ privacy very much, which is why we always keep these certificates encrypted using AES encryption algorithm and on top of that all communications with our servers are also protected using custom SSL certificates.
What are SSL certificates?
SSL (Secure Sockets Layer) certificates are digital certificates that are used to secure the communication between a website and its visitors. They are issued by trusted third-party certificate authorities (CA) and contain information about the identity of the website owner, the website’s domain name, and the public key needed to encrypt and decrypt data.
SSL certificates are essential for any website that handles sensitive information, as they provide a secure and encrypted connection that protects both the website owner and the users. This secure connection encrypts all data that is transmitted between the user’s browser and the website, ensuring that any sensitive information such as login credentials, credit card details, or personal data is kept safe.
Use case for custom SSL certificates
Certificates can be easily made and act as a security buffer. For example, a lot of times government agencies have their system only open to specific devices, which can be managed in various ways. One of them is using installed certificates – this way no unauthorized device will be able to connect to the website. The caveat for engineers working on test automatization on these websites is that a lot of times tests run in different environments (containers and remote servers), and it’s not always possible to manually set these certificates before starting test execution.
How to set it up (badssl.com test)
As an example, we will be setting up and testing a connection to https://client.badssl.com/ that requires a certificate made by BadSSL. To achieve this, all we have to do is download the custom certificate from BadSSL page. When you have the certificate you have to save the certificate and its password to Loadero using our API, and launch a test that will open the desired website. Try it out – here is the bare-bones script for each language to open the website and save a screenshot to validate the certificate worked. What we are expecting is a green background page with a success message as shown below.
Javascript
client => {
client.
url("https://client.badssl.com").
takeScreenshot("isCertSet.png");
}
Java
public void testUIWithLoadero() {
open("https://client.badssl.com")
.saveScreenshot("isCertSet.png");
}
Python
def test_on_loadero(driver: TestUIDriver):
driver.navigate_to("https://client.badssl.com")
driver.save_screenshot("certIsSet.png")
pass
Before starting the test, make sure you send the request (it has to be done once). Please do keep in mind that all tests from that project will have this certificate available. This bash script will need to be modified, to include your own certificate, API key, and project ID, but will help you send in the request with minimum effort. If you want to send the request without the help of this bash script, check out our swagger and search for an API endpoint “/projects/${PROJECT_ID}/files/”, do note that sending multiline JSON values is not possible, so the certificate needs to be updated to be in a single line with newlines represented by \n.
#!/bin/bash
input=$1
if [ -z "$1" ]; then
echo "No input file specified"
exit 1
fi
while IFS= read -r line
do
echo -n "$line\n" >> "ssl-copy.pem"
done < "$1"
value="`cat ssl-copy.pem`"
rm ssl-copy.pem
printf -v data '{ "file_type":"ssl-certificate", "password":"badssl.com", "content":"%s"}' "$value"
curl -X POST 'https://api.loadero.com/v2/projects/${PROJECT_ID}/files/' \
-H 'authorization: LoaderoAuth ${API_KEY}' \
-H 'content-type: application/json' \
-d "$data"
Drawbacks of using custom SSL certificates
As for all technological decisions, there are some drawbacks if you have to use custom SSL certificates in test automation. Most of them can be avoided with some work and modifications, but if you have no control over the process of creating these certificates these are some of the setbacks you can expect.
Multiple types of certificates
The main four types of certificates are PEM, PKCS#7, PKCS#12, DER. Each of these formats can have different types of data that are saved within it. For Loadero PEM format is recommended, as these certificates are ASCII encoded and can be opened in any text editor like notepad. The certificate should contain the certificate itself and also the RSA private key. These keys are saved in the file between lines -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- for the certificate and -----BEGIN ENCRYPTED PRIVATE KEY----- and -----END ENCRYPTED PRIVATE KEY----- for the private key. A good example of a working SSL certificate is the BadSSL provided .pem certificate. It can be downloaded from their page: https://badssl.com/download/
If your certificate is in any other format, it has to be remade to PEM format to use in Loadero.
Debugging
The user input for setting up SSL certificates in Loadero is minimal, with only one API request. But what happens if there are issues – the test participants open the website and they don’t have access? Debugging certificate issues can be quite time-consuming. To save you some time here are some debugging tips that have helped us.
- Launch the test in screen recording mode and check if it really does not have access, usually, the page does not load fully and will have some kind of error message.
- Set up the certificate on your machine and check if manually installing the certificate allows access to the desired page.
- Possibly the certificate is not complete – does not include a private key.
- Possibly the certificate is password protected – to use it, the password has to be also provided to Loadero.
- Be careful when sending in the certificate in Loadero. Formatting for the file is very important and will invalidate the certificate if formatting is off. Avoid adding additional indentation.
- If you are at a dead-end, we are always here to help, feel free to contact our support team. We will try to provide as much help as possible to detect any issues.
Lack of support for Mozilla Firefox
As much as we don’t like it, as of this moment we only support custom certificates for participants using the Google Chrome browsers. We are still looking into possibilities of how to support Mozilla Firefox because unfortunately, Firefox’s implementation of automatically selecting appropriate custom certificates is just not reliable enough for now – keep an eye out on our monthly change logs in the wiki and our blog for updates on this topic!
