Deaddrop is either installed from an ISO-file or by using a VHD-file for an Azure installation.
The installation is largely unattended—only the root password needs to be set manually. If installing in a virtualized environment, set the guest operating system type to Linux or Fedora for optimal compatibility. Once the system reboots, log in to the console to perform the remaining configuration steps.
To manually configure the IP address, edit the connection profile for the network interface using the vi text editor. The default file path is:
/etc/NetworkManager/system-connections/enp1s0.nmconnection
Note: The interface name (enp1s0) may vary depending on your hardware. Use ip a or nmcli device to confirm the correct interface name.
Open the connection file in vi:
vi /etc/NetworkManager/system-connections/enp1s0.nmconnection
Locate and edit the [ipv4] and [ipv6] sections:
[ipv4]
method=manual
address=1.2.3.4/24
gateway=1.2.3.1
dns=8.8.8.8;8.8.4.4
[ipv6]
method=disabled
Apply changes:
systemctl restart NetworkManager
Verify that the server is reachable with SSH.
The default partition layout may vary depending on the installation. To determine the current disk usage and layout, start by inspecting the partition table.
Use the following command to view the current mounted filesystems and their usage:
df -h
Look for the partition associated with /var mount point.
The setup uses LVM and you need to increase the size of the /var partition, you can extend it as needed. The following example expands /var by 100 GB:
/usr/sbin/lvextend -r -L+100G /dev/mapper/root_vg-lv_var
Depending on how many dispatches are created, other partitions like /var/log may need to be expanded to avoid running out of space.
Note: -L+100G: Increases the logical volume by 100 GB.
The server must be configured with a fully qualified domain name (FQDN). This FQDN should match the Subject Alternative Name (SAN) specified in the TLS certificate used for the deaddrop and ddadm server installation.
Configure the Hostname
Use the following command to set the system’s hostname:
/usr/bin/hostnamectl set-hostname servername.domain.tld
Replace servername.domain.tld with the actual FQDN assigned to the server.
SSL certificates are needed by the deaddrop service (TCP port 443) and by the ddadm administrative interface (TCP port 8443). Each has its own cert.conf and certificate folder, but they can share the same certificate. How you manage these certificates depends on how your organisation issues them. The sections below cover the two most common setups.
If your deployment uses Let’s Encrypt and the deaddrop-letsencrypt package is installed, certificates are installed and renewed automatically for both deaddrop and ddadm — no manual steps are needed.
Follow these steps to set up automatic certificate renewal with Let’s Encrypt:
1. Install Required Package
Install the deaddrop-letsencrypt package
dnf install deaddrop-letsencrypt
2. Configure Proxy Settings (If Necessary)
If your system uses a proxy, adjust the configuration file. It already contains commented examples to guide you:
vi /etc/sysconfig/deaddrop-letsencrypt
3. Configure Certificate Subject Alt Name
The Let’s Encrypt module relies on the wwwroot setting. If you don’t specify it, the server hostname is used by default.
vi /opt/sysctl/deaddrop/conf/admin.conf
Make sure the correct hostname is specified for the wwwroot to ensure proper certificate issuance and renewal.
4. Activate Let’s Encrypt
Run the following commands to request a certificate and enable automatic renewal:
/opt/sysctl/letsencrypt-deaddrop/scripts/get_certificate.sh
systemctl enable --now deaddrop-letsencrypt-renew.timer
If your organisation uses its own Certificate Authority (CA) or an external certificate vendor, you need to renew certificates manually when they expire.
If your CA issues the certificate on a separate system and gives you the certificate and private key files:
If you prefer to generate the certificate request directly on the DeadDrop server, follow these steps:
bash /opt/sysctl/deaddrop/admscripts/create_cert.sh
The script needs the server hostname to be correctly configured. It creates two files:
/root/pki/<hostname>.key — the private key, RSA 4096 (keep this secure). Reused if it already exists./root/pki/<timestamp>/<hostname>.csr — the certificate signing request to send to your CAopenssl req -text -noout -verify -in /root/pki/<timestamp>/<hostname>.csr
Send the .csr file to your CA and wait for the signed certificate back.
Convert the certificate to PEM format if needed. Your CA may return the certificate in a different format. The most common conversions are:
openssl x509 -inform der -in hostname.cer -out hostname.pem
openssl pkcs7 -in hostname.p7b -inform DER -print_certs -out hostname.pem
Deploy the certificate and key. Append the intermediate and root CA certificates to the certificate file, in that order, to complete the chain.
cat <hostname>.crt intermediate.crt root.crt > /root/pki/<hostname>.crt
The private key is still in /root/pki/ and must be copied into the certificate folder alongside the signed certificate:
cp /root/pki/<hostname>.key /opt/sysctl/deaddrop/etc/deaddrop/certs/
cp /root/pki/<hostname>.crt /opt/sysctl/deaddrop/etc/deaddrop/certs/
Edit cert.conf to point at the new certificate and private key:
vi /opt/sysctl/deaddrop/etc/deaddrop/conf.d/cert.d/cert.conf
Repeat the copy for /opt/sysctl/ddadm/etc/ddadm/certs/, or point ddadm’s cert.conf at the deaddrop copy — which is what Let’s Encrypt does.
To generate a new certificate signing request using the existing private key:
openssl req -new -key "/opt/sysctl/deaddrop/etc/deaddrop/certs/<hostname>.key" -out /root/<hostname>.csr -config /root/deaddrop.openssl.conf
This creates /root/<hostname>.csr. Send the contents of that file to your CA — the CA will use it to issue the renewed certificate. Once you receive the signed certificate back, place it and its full chain in the certificate folder described below.
The certificate paths are configured in:
/opt/sysctl/deaddrop/etc/deaddrop/conf.d/cert.d/cert.conf
/opt/sysctl/ddadm/etc/ddadm/conf.d/cert.d/cert.conf
The default locations are:
SSLCertificateFile → /opt/sysctl/deaddrop/etc/deaddrop/certs/deaddrop-dummy.certSSLCertificateKeyFile → /opt/sysctl/deaddrop/etc/deaddrop/certs/deaddrop-dummy.keySSLCertificateFile → /opt/sysctl/ddadm/etc/ddadm/certs/ddadm-dummy.certSSLCertificateKeyFile → /opt/sysctl/ddadm/etc/ddadm/certs/ddadm-dummy.keyYou can use different filenames (for example the server’s FQDN) as long as cert.conf points to them.
The certificate file must:
After placing certificate files on the server, make sure the files have the correct SELinux security label — without it the web server will not be able to read them. Copying files into the folder (cp) preserves the correct label automatically. Moving files with mv can break the label unless you use the -Z flag.
To fix or verify labels, run:
restorecon -Rv /opt/sysctl/deaddrop/etc/deaddrop/certs/
restorecon -Rv /opt/sysctl/ddadm/etc/ddadm/certs/
Reload the affected service so the new certificate is used:
systemctl reload deaddrop
systemctl reload ddadm-httpd
The default (out-of-the-box) configuration of DeadDrop is designed with a strong emphasis on security. All parameters are preconfigured to prioritize secure defaults and minimize attack surfaces.
At the same time, the setup provides flexibility for administrators to adjust key system and application parameters. This allows the deployment to be aligned with organizational policies and compliance requirements, without compromising the system’s core security posture.
The following settings are considered static, meaning they are not intended to be modified through the standard user interface. However, this configuration may evolve over time as future platform releases introduce new web-based configuration options within core system components (e.g., Apache).
The Deaddrop service, including its graphical administration interface, utilizes HTTPS (HTTP over TLS) to secure all communication between clients and the server.
TLS Cipher Suites
By default, DeadDrop is configured to accept only a limited set of secure and modern TLS cipher suites:
This curated list represents a security-focused subset of the full cipher suite selection available in TLS. It has been narrowed down to include only strong and widely supported options, ensuring both robust encryption and compatibility with modern web browsers.
Supported TLS Versions
The following protocol versions are supported by default:
Note: Older and insecure protocol versions—including TLS 1.1, TLS 1.0, and SSL—are explicitly disabled in the default configuration to reduce exposure to known vulnerabilities.
Security Enhancements
The system includes a preconfigured local firewall that restricts inbound traffic to a limited set of essential ports, enhancing the overall security posture.
The following inbound ports are allowed:
It is strongly recommended to restrict external access to the following TCP/IP ports, allowing connections only for trusted internal administrators:
It’s strongly recommended to block access, besides for the internal administrators access, to the following TCP/IP ports
These ports should not be exposed to the public internet unless absolutely necessary and properly secured (e.g., via VPN, jump hosts, or IP whitelisting).
Note: For a complete overview of all required firewall rules, refer to the Deaddrop network architecture diagram.
The following parameters are, or should be, configured to ensure secure and reliable operation of the DeadDrop platform. These settings may include defaults, recommended adjustments, or mandatory values based on your deployment environment and organizational policies.
All core service settings can be managed through the administrative web interface. This interface provides access to configuration options necessary for operating and securing the Deaddrop platform.
Note: Some advanced or low-level parameters may still require manual editing of configuration files, depending on deployment requirements.
All SMS-related settings can be managed directly through the administrative web interface. This includes configuring SMS gateways, authentication credentials, message templates, and delivery rules.
Note: Ensure that the configured SMS provider supports secure communication and complies with applicable data protection regulations.
To configure Deaddrop with SAML authentication or X.509 certificate-based access, please refer to the separate documentation provided by Sysctl.
By default, Deaddrop uses a preconfigured repository for receiving system and application updates. If a custom repository is required—such as for offline environments, staging workflows, or policy compliance—the default repository must be cloned and made accessible to the DeadDrop system.
Additionally, the package ddplugin-upgrade must be installed to support upgrades from a custom repository.
Configuring a Custom Repository
To enable DeadDrop to use a custom repository:
Set the configuration parameter local_repo to point to the desired repository configuration file.
Ensure that the specified file is correctly formatted and accessible.
Confirm that the repository mirror is complete and up-to-date.
Note: Once a custom repository is activated, all system updates must be performed via upgrade.service to ensure consistency and correct repository usage.
© Copyright sysctl Aktiebolag 2013-2025. All rights reserved
https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security ↩