Issues After Enabling TLS Connection in Compose File

Community Containers
1

Hey everyone,

I’ve been encountering a problem for the past few weeks that I can’t seem to resolve. This issue suddenly appeared despite not making any changes to the Compose file until recently.

Background: The only modification I made was enabling the TLS connection to allow other services to interact with it properly in subsequent automation processes.

Changes Made in the Compose File:

gvmd:
    image: registry.community.greenbone.net/community/gvmd:stable
    restart: on-failure
   +ports:
   +  - 9390:9390
   +environment:
   +  - GVMD_ARGS=--port=9390 --listen=0.0.0.0
    volumes:
      - gvmd_data_vol:/var/lib/gvm
      - scap_data_vol:/var/lib/gvm/scap-data/
      - cert_data_vol:/var/lib/gvm/cert-data
      - data_objects_vol:/var/lib/gvm/data-objects/gvmd
      - vt_data_vol:/var/lib/openvas/plugins
      - psql_data_vol:/var/lib/postgresql
      - gvmd_socket_vol:/run/gvmd
      - ospd_openvas_socket_vol:/run/ospd
      - psql_socket_vol:/var/run/postgresql
      - ${SSL_KEY}:/var/lib/gvm/private/CA/serverkey.pem
      - ${SSL_CRT}:/var/lib/gvm/CA/servercert.pem
    depends_on:
      pg-gvm:
        condition: service_started
      scap-data:
        condition: service_completed_successfully
      cert-bund-data:
        condition: service_completed_successfully
      dfn-cert-data:
        condition: service_completed_successfully
      data-objects:
        condition: service_completed_successfully
      report-formats:
        condition: service_completed_successfully

gsa:
    image: registry.community.greenbone.net/community/gsa:stable
    restart: on-failure
   +environment:
   + GSAD_ARGS: --mlisten=gvmd --mport=9390 --port=9443 --http-sts --no-redirect --gnutls-priorities=SECURE256:-VERS-TLS-ALL:+VERS-TLS1.2:+VERS-TLS1.3
    ports:
      - 9443:443
    volumes:
      - gvmd_socket_vol:/run/gvmd
      - ${SSL_KEY}:/var/lib/gvm/private/CA/serverkey.pem
      - ${SSL_CRT}:/var/lib/gvm/CA/servercert.pem
    depends_on:
      - gvmd
  # Sets log level of OpenVAS to the set LOG_LEVEL within the environment
  # and changes log output to /var/log/openvas instead of /var/log/gvm
  # to reduce the likelihood of unwanted log interferences

GVMD Logs: The logs indicate that GVMD is attempting to start initially, but it crashes.

md manage:MESSAGE:2025-01-03 13:51:36 UTC:24: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.111091:1 has changed from 'Report NVT debug logs' to 'Report VT debug logs'.
md manage:MESSAGE:2025-01-03 13:51:36 UTC:24: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.113120:1 has changed from 'API Username' to 'Icinga 2 API Username'.
md manage:MESSAGE:2025-01-03 13:51:36 UTC:24: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.113120:2 has changed from 'API Password' to 'Icinga 2 API Password'.
md manage:MESSAGE:2025-01-03 13:51:36 UTC:24: get_nvt_preference_by_id: name of preference 1.3.6.1.4.1.25623.1.0.12288:16 has changed from 'Mark host as dead if going offline (failed ICMP ping) during scan' to 'Mark host as dead if going offline (failed ICMP ping) during scan (deprecated)'.
User exists already.
md main-Message: 13:51:38.338: Greenbone Vulnerability Manager version 24.1.2 (DB revision 256)
md main-Message: 13:51:51.915: Greenbone Vulnerability Manager version 24.1.2 (DB revision 256)
starting gvmd
md main-Message: 13:52:06.961: Greenbone Vulnerability Manager version 24.1.2 (DB revision 256)

pg-gvm Logs: The PostgreSQL logs reveal connection issues:

Removed stale pid file.
The PostgreSQL server failed to start. Please check the log output:
2025-01-03 13:49:43.425 UTC [23] LOG:  starting PostgreSQL 13.18 (Debian 13.18-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2025-01-03 13:49:43.744 UTC [23] LOG:  listening on Unix socket "/tmp/.s.PGSQL.5432"
2025-01-03 13:49:45.454 UTC [24] LOG:  database system was interrupted; last known up at 2025-01-03 13:43:37 UTC
2025-01-03 13:49:46.519 UTC [24] LOG:  database system was not properly shut down; automatic recovery in progress
2025-01-03 13:49:46.792 UTC [24] LOG:  redo starts at 9/C9ADB1B8
2025-01-03 13:49:46.792 UTC [24] LOG:  invalid record length at 9/C9ADB2A0: wanted 24, got 0
2025-01-03 13:49:46.792 UTC [24] LOG:  redo done at 9/C9ADB268
2025-01-03 13:49:48.252 UTC [23] LOG:  database system is ready to accept connections
2025-01-03 13:50:36.163 UTC [101] LOG:  starting PostgreSQL 13.18 (Debian 13.18-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2025-01-03 13:50:36.163 UTC [101] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2025-01-03 13:50:36.163 UTC [101] LOG:  listening on IPv6 address "::", port 5432
2025-01-03 13:50:36.327 UTC [101] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2025-01-03 13:50:36.613 UTC [102] LOG:  database system was shut down at 2025-01-03 13:50:33 UTC
2025-01-03 13:50:36.903 UTC [101] LOG:  database system is ready to accept connections
2025-01-03 13:51:17.858 UTC [112] gvmd@gvmd WARNING:  there is already a transaction in progress
2025-01-03 13:51:19.019 UTC [112] gvmd@gvmd WARNING:  there is no transaction in progress
2025-01-03 13:52:06.969 UTC [123] gvmd@gvmd LOG:  could not receive data from client: Connection reset by peer

Additional Context: I followed the instructions from this post to configure the TLS connection, but the issue started appearing a few weeks ago. Interestingly, the error does not occur if I remove the port flag from the GVMD_ARGS environment variables in the gvmd and gsa services.

It seems unusual that specifying the port causes this issue, but without it, TLS does not function as intended.

Could there be additional configurations required for enabling TLS that I might have overlooked? Also, what could be causing the PostgreSQL connection to fail in this setup?

Any insights or suggestions would be greatly appreciated.

Thank you!

2

Hello,

there is a relevant comment about the TCP connection not being supported in general:

It uses the TCP connection for gvmd which is not supported nor tested from our side. Therefore we can’t ensure it works as expected.

2 Likes
3

Thank you for the response. In the openvas-scanner repository, it is mentioned that work is being done on an API implementation. I also came across the REST API in this context.

Do you know the current status of this implementation and whether it will be available in the community edition?

4

Unfortunately i have no knowledge / insight in such development / scanner / API specific topics.

5

You can see from this blog on the Greenbone Community Blog, that the new RESTful is intended for the Community Edition. It will be part of the openvas-scanner package. You can track the pull requests to see when it becomes implemented.