How to Enable HTTPS for Request Tracker on Linux

In this guide, you will learn how to enable HTTPS for Request Tracker on Linux. If you have already installed RT, it may currently be running over plain HTTP, which leaves your ticketing system vulnerable to eavesdropping. We’ll show you step by step how to secure your installation so all web traffic is encrypted and safe.

How to Enable HTTPS for Request Tracker on Linux

By default, Request Tracker (RT) is set to listen on HTTP (port 80) via the chosen web server. While this works out of the box, it leaves your network traffic unencrypted, which can expose sensitive information. For better security, it is highly recommended to upgrade your RT installation to use HTTPS, ensuring all data between your users and the server is encrypted.

To enable HTTPS, you need an SSL/TLS certificate. You have a few options:

• Self-signed certificates: Easy to create, but browsers will show warnings, and users must manually trust the certificate. Suitable mostly for internal testing.
• Commercial certificates: Trusted by default, but come at a cost and require proper domain validation.
• Let’s Encrypt certificates: Free, automated, and widely trusted. However, the domain must be publicly accessible. This doesn’t have to be the RT server’s exact FQDN but even a wildcard certificate for the domain also works.

In this guide, we will configure our RT instance to use Let’s Encrypt SSL/TLS certificates.

Let’s Encrypt uses the ACME protocol to validate domain ownership via either HTTP or DNS challenges. In this guide, we’ll focus on DNS validation using TXT records, which is often the most flexible for servers that aren’t directly exposed to the public internet.

Configure RT with HTTPS Using Let’s Encrypt

We’ve chosen Let’s Encrypt because it is free, widely trusted, and supports automated certificate issuance and renewal.

While our RT instance runs on a local network that is not exposed to the public Internet, we can still use Let’s Encrypt because our primary domain (kifarunix.com) is publicly accessible. We’ll issue a wildcard certificate this domain, which allows the certificate to secure our internal RT server without exposing it directly to the internet.

We’ll use DNS validation via TXT records to prove domain ownership, which is flexible and works even when the RT server itself isn’t publicly reachable. In this guide, we demonstrate this using Cloudflare as the DNS provider, but Let’s Encrypt supports many others, so the steps can be adapted to your environment.

So, let’s walk through the step-by-step process to issue the certificate and configure RT for HTTPS.

Step 1: Install Certbot

Certbot is the recommended ACME client to obtain Let’s Encrypt certificates. On most Linux distributions, you can install it via your package manager:

On Debian/Ubuntu:

sudo apt update

sudo apt install certbot python3-certbot-dns-cloudflare -y

On RHEL/CentOS/AlmaLinux/Rocky

sudo dnf install certbot python3-certbot-dns-cloudflare -y

Step 2: Create a DNS API Token for Let’s Encrypt

Let’s Encrypt needs to prove ownership of your domain when issuing certificates. For DNS validation, this usually involves creating TXT records on your domain provider.

To automate this process with Certbot, you’ll need an API token from your DNS provider (e.g., Cloudflare) that allows Certbot to create and verify the required TXT records. This makes certificate issuance and renewal fully automatic.

If you’re using Cloudflare, you can follow the steps in our previous guide to create a Cloudflare API token: Create a Cloudflare API Token

Step 3: Request a Certificate via DNS Challenge

Once the API token is ready, you can configure Certbot to use it for DNS validation.

Therefore, create a configuration file to store your API token:

sudo mkdir -p /etc/letsencrypt/dns

Enter this line into the tokens file replacing YOUR_CLOUDFLARE_API_TOKEN with your API token;

echo 'dns_cloudflare_api_token = YOUR_CLOUDFLARE_API_TOKEN' | sudo tee /etc/letsencrypt/dns/.cloudflare.ini

sudo chmod 600 /etc/letsencrypt/dns/.cloudflare.ini

Once you create the API token in a file, then use Certbot with DNS plugin to generate the SSL/TLS certificates for RT:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /path/to/cloudflare.ini \
  -d "*.example.com" \
  --preferred-challenges dns-01

Or you can do it non-interactively:

sudo certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials /path/to/cloudflare.ini \
  -d "*.example.com" \
  --preferred-challenges dns-01 \
  -n \
  --agree-tos \
  -m [email protected]

• --dns-cloudflare: Specifies Cloudflare DNS plugin.
• --dns-cloudflare-credentials: Path to your API credentials file.
• -d: Domains you want to secure.
• --preferred-challenges dns-01: Forces DNS validation.
• --agree-tos: Agree to the ACME server’s Subscriber Agreement
• -n: non-interactive option
• -m: Certs notification email

Certbot will automatically guide you through creating the necessary TXT records if your provider supports API automation. Otherwise, it will give the TXT values for you to add manually.

Sample output;

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Account registered.
Requesting a certificate for *.kifarunix.com
Waiting 10 seconds for DNS changes to propagate

Successfully received certificate.
Certificate is saved at: /etc/letsencrypt/live/kifarunix.com/fullchain.pem
Key is saved at:         /etc/letsencrypt/live/kifarunix.com/privkey.pem
This certificate expires on 2026-01-23.
These files will be updated when the certificate renews.
Certbot has set up a scheduled task to automatically renew this certificate in the background.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
 * Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
 * Donating to EFF:                    https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Step 4: Configure Apache for HTTPS

Now that you have successfully obtained your Let’s Encrypt SSL/TLS certificates, it’s time to configure your RT web server to serve traffic over HTTPS.

The key files we will use are:

• Certificate (full chain): /etc/letsencrypt/live/example.com/fullchain.pem
• Private key: /etc/letsencrypt/live/example.com/privkey.pem

These files are automatically updated by Certbot during renewal, so your web server configuration will continue to work without manual changes when the certificate is renewed.

Next, update your Apache (or other web server) configuration to point to these files and enable HTTPS for your RT instance.

Before you can proceed, ensure that the SSL modules is installed;

For RHEL distros:

sudo yum install mod_ssl

Before we can make the changes, this is how my default HTTP configuration (Running on AlmaLinux) is like:

cat /etc/httpd/conf.d/rt.conf

<VirtualHost *:80>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]
    
    AddDefaultCharset UTF-8
    ScriptAlias / /opt/rt6/sbin/rt-server.fcgi/

    DocumentRoot "/opt/rt6/share/html"

    <Directory "/opt/rt6/share/html">
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Directory>

    <Location />
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Location>

    ErrorLog /var/log/rt6/apache2.error
    CommonLog /var/log/rt6/apache2.access combined
    LogLevel debug
</VirtualHost>

For an Debian system, this is how the default HTTP config is like:

cat /etc/apache2/sites-enabled/rt.conf

<VirtualHost *:80>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]

    AddDefaultCharset UTF-8
    ScriptAlias / /opt/rt6/sbin/rt-server.fcgi/
    DocumentRoot "/opt/rt6/share/html"

    <Directory "/opt/rt6/share/html">
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Directory>

    <Location />
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Location>

    ErrorLog /opt/rt6/var/log/apache2.error
    CustomLog /opt/rt6/var/log/apache2.access combined
    LogLevel debug
</VirtualHost>

Note, there could be some little variations for your configs. They do not have to match line by line to our configs.

So, to configure Apache with HTTPS, this is our configuration for RHEL based hosts:

cat /etc/httpd/conf.d/rt.conf

Listen 443 https
SSLStaplingCache "shmcb:logs/stapling-cache(150000)"

<VirtualHost *:80>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]

    # Permanent redirect to HTTPS
    Redirect permanent / https://incidents.kifarunix.com/

    ErrorLog /var/log/rt6/httpd.error
    CustomLog /var/log/rt6/httpd.access combined
</VirtualHost>

<VirtualHost *:443>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]

    DocumentRoot "/opt/rt6/share/html"
    AddDefaultCharset UTF-8
    ScriptAlias / /opt/rt6/sbin/rt-server.fcgi/

    <Directory "/opt/rt6/share/html">
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Directory>

    <Location />
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Location>

    # Logging
    ErrorLog /var/log/rt6/httpd.error
    CustomLog /var/log/rt6/httpd.access combined

    # SSL Configuration
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/kifarunix.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/kifarunix.com/privkey.pem

    # Cipher suite & protocol hardening
    SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
    SSLProtocol -all +TLSv1.3 +TLSv1.2
    SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:prime256v1
    SSLHonorCipherOrder On
    SSLCompression off
    SSLUseStapling on
    SSLSessionTickets Off

    # Security headers
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set X-Frame-Options DENY
    Header always set X-Content-Type-Options nosniff
</VirtualHost>

Since we are using a single config file for both HTTP and HTTPS, let’s rename the default SSL config file.

mv /etc/httpd/conf.d/ssl.conf{,.old}

Check the config for any errors:

httpd -t

Ensure the result is: Syntax OK

Then restart HTTPD service:

systemctl restart httpd

For Ubuntu/Debian, this is our updated site configuration with HTTPS.

cat /etc/apache2/sites-enabled/rt.conf

# Redirect all HTTP traffic to HTTPS
<VirtualHost *:80>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]

    ErrorLog /opt/rt6/var/log/apache2.error
    CustomLog /opt/rt6/var/log/apache2.access combined

    # Permanent redirect to HTTPS
    Redirect permanent / https://incidents.kifarunix.com/
</VirtualHost>

# HTTPS VirtualHost with SSL/TLS hardening
SSLStaplingCache "shmcb:/run/apache2/stapling-cache(150000)"
SSLSessionCache shmcb:/run/apache2/sslcache(512000)
SSLSessionCacheTimeout 300

<VirtualHost *:443>
    ServerName incidents.kifarunix.com
    ServerAdmin [email protected]

    DocumentRoot "/opt/rt6/share/html"
    AddDefaultCharset UTF-8
    ScriptAlias / /opt/rt6/sbin/rt-server.fcgi/

    <Location />
        Require all granted
        Options +ExecCGI
        AddHandler fcgid-script fcgi
    </Location>

    # Logging
    ErrorLog /opt/rt6/var/log/apache2.error
    CustomLog /opt/rt6/var/log/apache2.access combined

    # SSL Configuration
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/kifarunix.com/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/kifarunix.com/privkey.pem

    # Cipher suite & protocol hardening
    SSLCipherSuite EECDH+AESGCM:EDH+AESGCM
    SSLProtocol -all +TLSv1.3 +TLSv1.2
    SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:prime256v1
    SSLHonorCipherOrder On
    SSLCompression off
    SSLUseStapling on
    SSLSessionTickets Off

    # Security headers
    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
    Header always set X-Frame-Options DENY
    Header always set X-Content-Type-Options nosniff
</VirtualHost>

Enable required modules:

a2enmod fcgid ssl headers socache_shmcb rewrite

Check the configuration for any syntactical errors:

apachectl -t

Ensure the result is: Syntax OK

Step 5: Opening Port 443 for HTTPS Traffic on Firewall

To ensure that your Apache server is accessible via HTTPS, you need to allow traffic on port 443.

Confirm the HTTPS service is up:

ss -altnp | grep :443

Sample output;

LISTEN 0      511                *:443             *:*    users:(("httpd",pid=14448,fd=6),("httpd",pid=14268,fd=6),("httpd",pid=14267,fd=6),("httpd",pid=14266,fd=6),("httpd",pid=14265,fd=6),("httpd",pid=14263,fd=6))

If you are running Ubuntu/Debian or similar distros and using UFW:

ufw allow 443/tcp

If you are using iptables:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

iptables-save > /etc/iptables/rules.v4

If you are using firewalld (common on RHEL/CentOS/Fedora):

firewall-cmd --add-port=443/tcp --permanent

firewall-cmd --reload

Step 6: Test RT HTTPS Access

The certificates are now installed for RT. To verify that it works as expected:

• Open your browser: https://rt-domain.com
• Confirm the certificate is valid and the connection is secure.

And that confirms we are all setup.

Step 7: Let’s Encrypt Automatic SSL Certificate Renewal

Let’s Encrypt certificates expire every 90 days. You can manually renew them using the command:

certbot renew --quiet

However, this process can be automated via a cron job or systemd timer, provided that DNS API access is configured. This is especially important for DNS-validated certificates, as automatic renewal relies on API access to your DNS provider to update DNS records.

To automatically renew your certificates, you can set up a cron job to run periodically (e.g., every day). Hence:

Open your crontab file for editing:

sudo crontab -e

Add a new cron job to check for renewals daily at a specific time (e.g., 2:30 AM):

30 2 * * * certbot renew --quiet --post-hook "systemctl reload httpd"

Save and exit the editor.

This cron job will now run daily at 2:30 AM and attempt to renew any certificates that are near expiration, provided the necessary API access is configured.

Conclusion

With HTTPS successfully implemented, Request Tracker is now secure for use, protecting sensitive ticketing data and user interactions.