Current Behavior:

Currently http only requests to the docker containers are supported. http://dependencytrack.domain.com:8080

Proposed Behavior:

Add https support for https connections and certificates for Let's Encrypt and other certificate authorities https://dependencytrack.domain.com:8443 --- https main page API_BASE_URL=http://thunder.pargovernment.net:8444 --- updated config for https

Proposed changes for the docker-compose.yml ALPINE_SSL_CERTIFICATE_FILE=/etc/letsencrypt/live/dependencytrack.domain.com/fullchain.pem ALPINE_SSL_CERTIFICATE_KEY_FILE=/etc/letsencrypt/live/dependencytrack.domain.com/privkey.pem ALPINE_SSL_CERTIFICAT_CHAIN_FILE=/etc/letsencrypt/live/thunder.pargovernment.net/chain.pem ALPINE_INCLUDE/etc/letsencrypt/options-ssl-apache.conf

The simplest way would be to put NGINX in from the the API Server ad Frontend and let NGINX handle TLS. This is what most organizations do today.

Future versions of Dependency-Track will ship with more and more smaller components (e.g. CycloneDX BOM Repo Server, etc), managing certificates on every container will be problematic.

I'm working with apache and fight CORS which I just submitted a bug for. I'm not apposed to switching to NGINX to proxy it. Would you happen to have a known working configuration? I can't seem to get the right combination. I have many other webapp servers. The configuration for DependencyTrack seems to be working a little different.

@croniserb maybe this will help. Create config for both components frontend and API server. Then also configure Dependency-Track to use the HTTPS endpoint API from the frontend... I set this up using an AWS ELB and it took me about 1 hour to properly configure it... because the frontend needed to be configured to use the https endpoint.

It would probably be a good idea to have a wiki page or something with some info on a couple of scenarios adding HTTPS. Its not complicated, its just a little bit hidden in the config and you need to read the manual, just the docker compose up instruction is a bit misleading.

@webmutation Interesting. I'm using an AWS EC2 instance. If I set

• API_BASE_URL=https://system.domain.net:8081 I get SSL PROTOCOL ERROR. That would be expected because HTTPS is not configured inside the container. Stepping back one level to the apache proxy, https can't be set on the proxy URL or I get proxy errors. I would be interested to learn more with how you used AWS ELB for your deployment. I don't work with AWS ELB too much.

If you are using an EC2 instance, you can create an ELB or use Apache... its all about routing the requests to the right application.

In this ELB type Application you can create two HTTPS Listener 443 for Frontend and 8443 or whatever other port to use for the API. Then you will have two Target Group type instance pointing to the same instance where you have DT installed. In one Target group you point to 8080 (default frontend port) and on the other Target Group you point to 8081 (default API server port)

If you want to just use Apache you can also do that, it will be similar create two virtual host application one running on port 443 the other on port 8443 or 444 and put in place TLS termination. You can use Letsencrypt for the SSL certs.

Since the UI communicated with the backend you can also use local traffic with rewrite rules. etc... but its better to have TLS all over so you dont have mixed http/https content warnings...

There are many ways to get this to work. In my case I use ELB because its simpler for me with ACM.

The most important take-away is that with the new distribution model in 4.x you have to treat them as separate apps that are connected via the config file. Hope this helps... I will try to contribute a guide to the Docs for a couple of use cases.

So I fully agree with @stevespringett TLS termination should be the responsibility of the LB or RP.

@webmutation I think that was the cookie crumb I needed. I think I was creating a loop by having API_BASE_URL=https://system.domain.net:8081 still defined in docker-compose.yml. By commenting that out, I think I'm running. The webfrontend is proxied on 8080 for /. /api is proxied on 8081. Both are on 443 with Let's Encrypt.

I am successful at logging. I do see this error that has me concerned that I don't have something configured just right yet. @stevespringett Is there something I am missing still?
vue.esm.js:1906 TypeError: Cannot read properties of undefined (reading 'includes') at a.mounted (DefaultContainer.vue:147:1) at oe (vue.esm.js:1872:57) at Hn (vue.esm.js:4244:7) at Object.insert (vue.esm.js:3167:7) at E (vue.esm.js:6401:28) at a.patch (vue.esm.js:6620:5) at a.Rn.t._update (vue.esm.js:3972:19) at a.r (vue.esm.js:4090:10) at or.get (vue.esm.js:4504:25) at or.run (vue.esm.js:4579:22)

The last error appears to have been due to browsers caching. I am not seeing that error now.

I'm working with apache and fight CORS which I just submitted a bug for. I'm not apposed to switching to NGINX to proxy it. Would you happen to have a known working configuration? I can't seem to get the right combination. I have many other webapp servers. The configuration for DependencyTrack seems to be working a little different.

The docker frontend of DependencyTrack already ships with NGINX and you could use it as a reverse proxy for the backend part.

At least this is what I've done.

`

Compose.yml

Modify the docker-compose.yml frontend part, so that a local default.conf for NGINX is mapped into the container, the API_BASE_URL is set correctly and the new API ports are addded to the list. Copy the certificate files to "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/". Set the appropriate accessrights!

dtrack-frontend:
    image: dependencytrack/frontend
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=https://dtrack.example.local:8443
    volumes:
      - 'dependency-frontend:/data:ro'
      - "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/default.conf:/etc/nginx/conf.d/default.conf"
    ports:
      - "80:8080"
      - "443:9443"
      - "8443:8443"

NGINX Reverse Proxy Setup

server {
        listen      8080;
        listen [::]:8080 default_server;

        server_name _;

        return 301 https://$host$request_uri;
}

server {
    listen 9443 ssl;

    server_name dtrack.example.local;

    ssl_certificate /data/cert-pub.pem;
    ssl_certificate_key /data/cert-priv.key;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    client_max_body_size 12m;

    location / {
                root      /app;
                index     index.html;
                try_files $uri $uri/ /index.html;
    }

        error_page 500 502 503 504 /50x.html;

        location = /50x.html {
                root /usr/share/nginx/html;
        }
}

# Reverse Proxy Setup for the Backend
server {
    listen 8443 ssl;

    server_name dtrack.example.local;

    ssl_certificate /data/cert-pub.pem;
    ssl_certificate_key /data/cert-priv.key;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    client_max_body_size 12m;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://dtrack.example.local:8081;
        proxy_read_timeout 90;
        proxy_redirect http://dtrack.example.local:8081 https://dtrack.example.local;
    }
}

`

Hello @bytew0lf, I've been struggling to set up the certificate I've been delivered for my instance of dependency-track and your configuration feels like the closest I've gotten to understanding any of it.

I just have a couple of questions about what you've written:

• what access rights do the certificate files and the default.conf file need?
• do you think you could highlight which parts of the conf file I have to change to adapt it to my configuration ? I understand that "example" lines have to be changed and I think all the dollar sign variables have to be as well, but I'm not sure about some parts ("default_server", "server_name")

Thanks.

Hi @GHSebamo, the access rights for certificate files are 644 and the rights for the default.conf 664 in my case. All the files belong to the user "root"

You can leave the first server section of the default.conf alone, this is just for redirecting every request from http to https.

The second server section is for the frontend there you only have to change the server name to the FQDN of your server and maybe the names of the certificate files.

The third server section is the reverse proxy for the REST API, there you have to change the server name to the FQDN of your server and the variables proxy_pass and proxy_redirect so that dtrack.example.local is exchanged with your server FQDN.

The dollar sign variables can be left as is.

Hope that helps.

Quick FYI for anyone else following the instructions provided by @bytew0lf (thank you btw!) The internal root directory for nginx in the docker image has changed since bytew0lf's posting. it is now /opt/owasp/dependency-track-frontend instead of /app. Therefore, the updated nginx.conf template would be:

server {
        listen      8080;
        listen [::]:8080 default_server;

        server_name _;

        return 301 https://$host$request_uri;
}

server {
    listen 9443 ssl;

    server_name dtrack.example.local;

    ssl_certificate /data/cert-pub.pem;
    ssl_certificate_key /data/cert-priv.key;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    client_max_body_size 12m;

    location / {
                root      /opt/owasp/dependency-track-frontend;
                index     index.html;
                try_files $uri $uri/ /index.html;
    }

        error_page 500 502 503 504 /50x.html;

        location = /50x.html {
                root /usr/share/nginx/html;
        }
}

# Reverse Proxy Setup for the Backend
server {
    listen 8443 ssl;

    server_name dtrack.example.local;

    ssl_certificate /data/cert-pub.pem;
    ssl_certificate_key /data/cert-priv.key;
    ssl_session_cache builtin:1000 shared:SSL:10m;
    ssl_prefer_server_ciphers on;

    access_log /var/log/nginx/access.log;
    client_max_body_size 12m;

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_pass http://dtrack.example.local:8081;
        proxy_read_timeout 90;
        proxy_redirect http://dtrack.example.local:8081 https://dtrack.example.local;
    }
}

Search terms to make sure this can be found:

rewrite or internal redirection cycle while internally redirecting

@alexbartok I was reading the topic and you just commented, thanks

Following the instructions that @bytew0lf passed, I managed to make HTTPS work in my DT,

I would like to thank @bytew0lf and @alexbartok for the help given to the DT community.

@bytew0lf I have a self signed certificate and its giving me https://10.33.0.50:8443/api/version net::ERR_CERT_COMMON_NAME_INVALID. How can i handle it any help is appreciated.

Hi @vishal-gurnaney, I suppose you already added the CAs Certificate to your computers Certificate Store as Trustworthy Certificate Authority, so that the validation can be done. When you create the self-signed certificate you need to set the Common Name (CN) to the name you'll use in the address bar. For instance https://foo.bar -> CN = foo.bar. You can also set multiple "CNs" with the SubjectAlternativeName (SAN) so the certificate is valid for multiple Domains/IPs. If you use OpenSSL you can follow this article https://security.stackexchange.com/questions/74345/provide-subjectaltname-to-openssl-directly-on-the-command-line. To provide an IP as a SAN just modify the addext parameter. openssl req -new -subj "/C=GB/CN=foo" -addext "subjectAltName = DNS:foo.co.uk, IP:10.33.0.50" -newkey rsa:2048 -keyout key.pem -out req.pem

Linode has a good article about multiple SANs in one certificate: https://www.linode.com/docs/guides/using-openssls-subjectaltname-with-multiple-site-domains/

Hope that helps you out.

Thanks for the reply @bytew0lf. I have actually create SAN for the certificate, still i am facing the issue, the error message seems to be misleading.

#openssl x509 -text -noout -in C:\Setups\DependencyTrack\Certificates\tool.dependency.track.crt | grep DNS

          DNS:tool.dependency.track

Am i missing something here ?

Thanks for the reply @bytew0lf. I have actually create SAN for the certificate, still i am facing the issue, the error message seems to be misleading.

#openssl x509 -text -noout -in C:\Setups\DependencyTrack\Certificates\tool.dependency.track.crt | grep DNS

          DNS:tool.dependency.track

Am i missing something here ?

You'll have to specify the IP as well in the SAN, not only the the DNS if you access the system with the IP, like you showed in your previous post. That's what worked for me in my setup.

@bytew0lf yes I modified it specified both IP and DNS it worked for me.

@bytew0lf i am trying to build CI\CD pipeline using the API i am trying to upload the BOM file. "But facing Uploading the BOM to Dependency Track Failed: {"code":"UNABLE_TO_VERIFY_LEAF_SIGNATURE"} " I have added the certificate. Any help or hints appreciated.

Hi @vishal-gurnaney , @bytew0lf and @viniciusnavarro I am able to access the frontend server but unable to access the backend API via using https://localhost:8443 from by browser but able to access http://localhost:8081

Nignx Config

server { listen 8080; listen [::]:8080 default_server;

    server_name _;

    return 301 https://$host$request_uri;

} server { listen 9443 ssl;

server_name localhost;

ssl_certificate localhost.crt;
ssl_certificate_key localhost.key;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_prefer_server_ciphers on;

access_log /var/log/nginx/access.log;
client_max_body_size 12m;

location / {
            root      /opt/owasp/dependency-track-frontend;
            index     index.html;
            try_files $uri $uri/ /index.html;
}

    error_page 500 502 503 504 /50x.html;

    location = /50x.html {
            root /usr/share/nginx/html;
    }

} server { listen 8443 ssl; server_name localhost; ssl_certificate localhost.crt; ssl_certificate_key localhost.key; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_prefer_server_ciphers on; access_log /var/log/nginx/access.log; client_max_body_size 12m; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_pass http://localhost:8081; proxy_read_timeout 90; proxy_redirect http://localhost:8081 https://localhost; } }

Docker Compose

Consol Error

API Server

Error

@bytew0lf I am facing the CORS issue, I followed all steps.

I have resolved CORS issue by adding additional parameters:

	proxy_hide_header Access-Control-Allow-Origin;
        add_header 'Access-Control-Allow-Origin' '*' always;

However 504 error is still there unable to access xxx:8443/api/*.

The simplest way would be to put NGINX in from the the API Server ad Frontend and let NGINX handle TLS. This is what most organizations do today.

Future versions of Dependency-Track will ship with more and more smaller components (e.g. CycloneDX BOM Repo Server, etc), managing certificates on every container will be problematic.

@stevespringett agree, but why don't DT use this "simple" approach as default but rather expose API server via HTTP? As you said , this is what most organizations do today, and most of them hide API server behind Nginx reverse proxy. DT is a cybersecurity focused tool, and I believe most people agree using Https rather than Http for better security. Just don't get it why DT still stick on Http?

@bytew0lf @alexbartok https works via this when connecting to dtrack-frontend, but dtrack-apiserver still expose port 8081 via http to outside, can we use https instead?

    proxy_pass http://dtrack.example.local:8081;
    proxy_read_timeout 90;
    proxy_redirect http://dtrack.example.local:8081 https://dtrack.example.local;

I have resolved CORS issue by adding additional parameters:

	proxy_hide_header Access-Control-Allow-Origin;
        add_header 'Access-Control-Allow-Origin' '*' always;

However 504 error is still there unable to access xxx:8443/api/*.

Access issue also resolved, that was of misconfigurations of ports at host machine, everything is working now, Thanks @bytew0lf and everyone else who contributed.

For the record, Gitea's docker installation allows HTTPS through the docker-compose.yml through this syntax which it puts in it's app.ini that nginx reads

      - GITEA__Server__ROOT_URL=https://{url}:3000/
      - GITEA__server__PROTOCOL=https
      - GITEA__server__CERT_FILE=/etc/certs/cert.crt
      - GITEA__server__KEY_FILE=/etc/certs/cert.key
      - GITEA__server__REDIRECT_OTHER_PORT=true
      - GITEA__server__PORT_TO_REDIRECT=3080

Hello all,

I'm also struggling with deploying dependency-track using https. When I try to start via docker-compose I get an error:

service "dtrack-frontend" refers to undefined volume dependency-frontend: invalid compose project

I did the following steps:

• edit the docker-compose file as mentioned
• did the nginx.conf (with /opt/owasp/dependency-track-frontend instead of /app)
• copied the certificate files to /var/lib/docker/volumes/deptrack_dependency-track/_data
• set the access rights to the files 644 and 664

The compose file looks something like this:

version: '3.7'


volumes:
  dependency-track:

services:
  dtrack-apiserver:
    image: dependencytrack/apiserver
    environment:
    - ALPINE_DATABASE_MODE=external
    - ALPINE_DATABASE_URL=jdbc:[PATH_TO_SERVER]
    - ALPINE_DATABASE_DRIVER=com.microsoft.sqlserver.jdbc.SQLServerDriver
    - ALPINE_DATABASE_USERNAME=deptrack
    - ALPINE_DATABASE_PASSWORD=[SOMETHING]

    deploy:
      resources:
        limits:
          memory: 12288m
        reservations:
          memory: 8192m
      restart_policy:
        condition: on-failure
    ports:
      - '8081:8080'
    volumes:
      - 'dependency-track:/data'
      - "/etc/pki/ca-trust/extracted/java/cacerts:/opt/java/openjdk/lib/security/cacerts:ro"
    restart: unless-stopped

  dtrack-frontend:
    image: dependencytrack/frontend
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=https://deptrack.company.net:8443
    volumes:
      - 'dependency-frontend:/data:ro'
      #- "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/:/data:ro"
      - "/var/lib/docker/volumes/dtrack_dependency-frontend/_data/default.conf:/etc/nginx/conf.d/default.conf"
    ports:
      - "80:8080"
      - "443:9443"
      - "8443:8443"
    restart: unless-stopped

Could somebody please give me a hint?

Thanks for help!

In the section called "volumes" it's missing the volume "dependency-frontend"

Would be like this:

volumes:
  dependency-track:
  dependency-frontend:

yuenfaytsang built something that works out of the box:

Warning We use run NGINX as systemd Service on the docker host and do NOT use the internal NGINX

the docker-compose is pretty much vanilla:

version: '3.7'

volumes:
  dependency-track:

services:
  dtrack-apiserver:
    image: dependencytrack/apiserver
    deploy:
      resources:
        limits:
          memory: 12288m
        reservations:
          memory: 8192m
      restart_policy:
        condition: on-failure
    ports:
      - '8081:8080'
    volumes:
      - 'dependency-track:/data'
    restart: unless-stopped

  dtrack-frontend:
    image: dependencytrack/frontend
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=https://deptrack.localdomain
    ports:
      - "8080:8080"
    restart: unless-stopped

The magic happens in the NGINX configuration:

server {
  listen 80;
  server_name deptrack.localdomain;

  ### SEND 404 IF HOSTNAME DOES NOT MATCH
  if ($host !~ ^(deptrack.localdomain)$ ) { return 404; }

  ### REDIRECT HTTP TO HTTPS
  return 301 https://$host$request_uri/;
}

server {
  listen 443 ssl http2;
  server_name deptrack.localdomain;

  ### SEND 404 IF HOSTNAME DOES NOT MATCH
  if ($host !~ ^(deptrack.localdomain)$ ) { return 404; }

  ### TLS CERTIFICATES
  ssl_certificate /etc/pki/tls/certs/deptrack.crt;
  ssl_certificate_key /etc/pki/tls/private/deptrack.key;

  ### TLS HARDENING
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_prefer_server_ciphers on;
  ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH EDH+aRSA HIGH !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";

  ### DEPENDENCY TRACK FRONTEND
  location / {
    proxy_pass http://localhost:8080/;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
  }

  ### DEPENDENCY TRACK APISERVER
  location /api/ {
    proxy_pass http://localhost:8081/;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
  }

  ### PREVENT SERVING HIDDEN FILES
  location ~ /\. {
    deny all;
    return 404;
  }
}

All that needs to be done is to replace deptrack.localdomain with your hostname and the TLS Certificate and Key files need to be added.

This config uses only Port 443 to the outside of the host. To reach the API use deptrack.localdomain/api

  dtrack-frontend:
    image: dependencytrack/frontend
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=https://deptrack.localdomain
    ports:
      - "8080:8080"
    restart: unless-stopped

Thanks for config! But in my experience it turned out to be more correct to specify

  dtrack-frontend:
    image: dependencytrack/frontend
    depends_on:
      - dtrack-apiserver
    environment:
      - API_BASE_URL=https://deptrack.localdomain/**api**
    ports:
      - "8080:8080"
    restart: unless-stopped

Otherwise, all requests to the api did not work correctly. However, a more correct fix is to change the configuration of nginx:

  location /api/ {
    proxy_pass http://localhost:8081/**api/**;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_hide_header X-Powered-By;
    proxy_hide_header Server;
  }