Custom SSL Certificate for Security Onion Web UI
TL;DR
These steps assume a certificate signed by your certificate authority of choice has already been generated. To install the certificate on the web UI of Security Onion (SO) you will need a certificate file and a private key file. Not that if you are accessing the web UI by IP address instead of FQDN, the IP address will need to be declared in the certificate. Follow the steps below to install the certificate on the SO manager node; all commands are run as root
.
- Copy the certificate and private key file to the Security Onion manager node.
- Backup the existing certificate and respective private key by running the following commands:
1mv /etc/pki/managerssl.crt /etc/pki/managerssl.crt_bu
2mv /etc/pki/managerssl.key /etc/pki/managerssl.key_bu
- Replace the files referenced above with your certificate and private key. In the case of a Let’s Encrypt certificate I used the
<domain>.fullchain.pem
file and the<domain>.privkey.pem
file.
1cp <domain>.fullchain.pem /etc/pki/managerssl.crt
2cp <domain>.privkey.pem /etc/pki/managerssl.key
- Restart the NGINX web server container that is running the web interface,
so-nginx
, by running the following command:
1docker restart so-nginx
- Wait a few minutes then check that your certificate has been installed properly by navigating to your web manager’s URL.
What is Security Onion
From its website:
Security Onion (SO) is a free and open Linux distribution for threat hunting, enterprise security monitoring, and log management. Security Onion includes Elasticsearch, Logstash, Kibana, Suricata, Zeek (formerly known as Bro), Wazuh, Stenographer, TheHive, Cortex, CyberChef, NetworkMiner, and many other security tools.
I deployed SO 2.3.90 as a standalone node in my home network to get better visibility into the network and to get some experience threathunting. For network visibility I am mirroring the traffic between the core switch and the firewall to the monitoring port of the SO node while for endpoint visibility I’ve deployed agents on Windows and Linux machines.
Web Interface
Interaction with the tools included in SO happens through a web interface that uses a self-signed SSL certificate for HTTPS which inevitably leads to the following well-known error:
It’s not a big deal in a home network (self-signed certs are often deployed throughout enterprise networks too) but I’ve been on an HTTPS-all-the-things binge.
The Security Onion web insterface is served up by an NGINX web server running in the container so-nginx
. By inspecting the properties of this container with the command docker inspect so-nginx
I found which local files are mounted in the container, and more specifically to the NGINX certificate files.
1docker inspect so-nginx
2 ...
3 "Mounts": [
4 ...
5 {
6 "Type": "bind",
7 "Source": "/etc/pki/managerssl.crt",
8 "Destination": "/etc/pki/nginx/server.crt",
9 "Mode": "ro",
10 "RW": false,
11 "Propagation": "rprivate"
12 },
13 ...
14 {
15 "Type": "bind",
16 "Source": "/etc/pki/managerssl.key",
17 "Destination": "/etc/pki/nginx/server.key",
18 "Mode": "ro",
19 "RW": false,
20 "Propagation": "rprivate"
21 },
22 ...
By replacing the managerssl.crt
and managerssl.key
files on the local file system and restarting the so-nginx
container I was able to deploy my own certificates to the web interface.
References
In building the steps above I referenced this GitHub issue from the Security Onion repository.