Search for a command to run...
Acquire private Trusted Root Certification Authority
Currently working as a Senior Consultant at Netcompany spending my full-time job solving the SharePoint riddles. In the free time I'm expanding my understanding of cybersecurity through hacking activities. Git fanboy.
No comments yet. Be the first to comment.
Installation, configuration and orchestration of Kasm Workspaces running on the Raspberry Pi. Kasm Workspaces allows streaming containerized apps and desktops to the end-users.
Installation and initial configuration steps
A Deep Dive into Rootkit Detection via Linux Memory Forensics - HackTheBox Business CTF 2025
💡 This write-up is a part of the HTB Sherlocks series. Sherlocks are investigative challenges that test defensive security skills. I encourage you to try them out if you like digital forensics, incident response, post-breach analysis and malware ana...
Hack The Box Sherlock write-up
💡 This write-up is a part of the HTB Sherlocks series. Sherlocks are investigative challenges that test defensive security skills. I encourage you to try them out if you like digital forensics, incident response, post-breach analysis and malware ana...
Hack The Box CTF Cyber Apocalypse 2025: Tales from Eldoria
Based on Create Your Own SSL Certificate Authority for Local HTTPS Development
Yes and no. In some web projects, you can slip through the default "I know, just let me in" option in browsers. But nowadays, it is hard to find a website that doesn't load the JavaScript - and browser won't let you load a JS from the external sources when certificate is not valid.
From the security point of view - you should not deliver solutions that with invalid certificate. There was a question on the Reddit asked by cool-thinker - if such invalid certificate cases connection to be not encrypted. Let's see it now.
There is a great step-by-step wiki on the HTTPS traffic analysis with Wireshark. By applying this knowledge for the current Kasm Workspaces URL with invalid certificate, you can see that the data is encrypted.
Don't let it cloud your judgement, though - danger does not come from the lack of encryption, but from the lack of knowledge if the party that signed that certificate can be trusted.
Let's Encrypt is a well-known, trusted Certificate Authority that allows everyone with the accepted TLD (top-level domain, like *.com or *.org) to generate secure certificate for their websites' SSL connections.
From Let’s Encrypt Community Support:
These are two distinct “systems” with distinct choices (choose one per domain):
- Use a private certificate [private CA] for a private domain.
- Use a public certificate [LetsEncrypt] for a public domain.
Another, similar response: Can I create a cert for a private domain?
In our example, we have a private domain that would like to be trusted by the public certificate of Let's Encrypt - that won't work. If we tried to do that:
So now, our plan is:
Generate CA private key:
$ openssl genrsa -aes256 -out cybethme-ca.key 2048
Generate CA Root Certificate (10ys validity):
$ openssl req -x509 -new -nodes -key cybethme-ca.key -sha256 -days 3650 -out cybethme-ca.pem
ca-certificates expects PEM files with *.crt extension, so let's give it to him:
$ sudo cp cybethme-ca.pem /usr/local/share/ca-certificates/cybethme-ca.crt
$ sudo update-ca-certificates
# sudo update-ca-certificates --fresh / to rebuild from scratch
$ awk -v cmd='openssl x509 -noout -subject' '/BEGIN/{close(cmd)};{print | cmd}' < /etc/ssl/certs/ca-certificates.crt | grep Cyber
Generate private key:
$ openssl genrsa -out kasm.rpi.key 2048
Create Certificate Signing Request (CSR):
$ openssl req -new -key kasm.rpi.key -out kasm.rpi.csr
Create ext file (kasm.rpi.ext) to supply during making a signing request.
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = kasm.rpi
Create signed certificate for the Kasm:
$ openssl x509 -req -in kasm.rpi.csr -CA cybethme-ca.pem -CAkey cybethme-ca.key -CAcreateserial -out kasm.rpi.crt -days 730 -sha256 -extfile kasm.rpi.ext
Now you have the CRT certificate that can be used in application.
You may notice that additional SRL file for Root CA is created. It is required by OpenSSL to track serial number of generated certificates - read more about it here.
SSH into Kasm server and replace certificate and the private key:
$ sudo /opt/kasm/bin/stop
$ sudo cp ~/.certs/kasm.rpi.crt /opt/kasm/current/certs/kasm_nginx.crt
$ sudo cp ~/.certs/kasm.rpi.key /opt/kasm/current/certs/kasm_nginx.key
$ sudo /opt/kasm/bin/start
Copy CA Root Certificate to the systems that will be using the Kasm Workspaces. It depends on the system, but on Windows - double-click the certificate and import it to Local Machine (or Current User) in Trusted Root Certification Authorities.
Change hosts entry (on endpoint) to point chosen Kasm address to the IP address.
192.168.0.105 kasm.rpi
Now we have access to the Kasm Workspaces without errors on the browser.
Unfortunately, this is not the end. When I tried to launch an image, I've got an error message. Last step is changing the Upstream Auth Address for the default zone to the local IP address:
So far, we have a working Kasm Workspaces installation that we can connect via secure SSL connection. After making the device accessible over the Internet, you can perform containerized operations from any system using a browser. In the next tutorials, I will showcase how you can add more images to the Kasm and how you can persist data between sessions.
Check out other guides from the Kasm Workspaces Rapberry Pi series.