Secure Frontend Webinterface (GSAD) with Let's Encrypt SSL/HTTPS certificate

Hi there!

I installed GVM from source with this guide:
https://www.libellux.com/openvas/#install-openvas-20-08-from-source

Now I wanted the secure the Frontend Webinterface with Let’s Encrypt SSL/HTTPS certificate using the following guides, without success.
https://community.greenbone.net/t/gsad-ssl-certificate/6651
https://lists.wald.intevation.org/pipermail/openvas-discuss/2014-February/005800.html
https://lists.wald.intevation.org/pipermail/openvas-discuss/2017-October/011524.html
https://wiki.alpinelinux.org/wiki/Setting_up_OpenVAS9
https://www.xinux.net/index.php/Openvas_Webinterface_Letsencrypt

Does anyone already got this working?
Everything else is working just fine.
Many thanks,

GVM versions

gsad: Greenbone Security Assistant 20.08.0~git-17a736a39-gsa-20.08
gvmd: Greenbone Vulnerability Manager 20.08.0~git-0754740a-gvmd-20.08
openvas-scanner: OpenVAS 20.8.0 gvm-libs 20.8.0~git-3597093-gvm-libs-20.08
gvm-libs:

Environment

Operating system:
Kernel: Linux vmvs2 5.4.0-52-generic #57-Ubuntu SMP Thu Oct 15 10:57:00 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
Installation method / source: from source

You need to do the DNS Challenge for Let’s Encrypt, GSA does not allow the let’s encrypt probes via Web-Services so the HTTP challenge will not work.

1 Like

Hello @w.reidlinger,

If you haven’t got it to work yet I could try push it into my next update of the OpenVAS chapter. Planning to release it sometime tomorrow, I’ve used Lets Encrypt before but when using nginx proxy. However, I would then of course cover Lets Encrypt standalone without the nginx proxy.

Best regards,
Fredrik

Thanks for the info, but I’m aware of this fact and already did the DNS challenge and is also worked.
The only problem is, that I can’t tell the GSA webservice to use the lets encrypt certificates.

Just call them with the command line when you start GSAD … “gsad --help” will give your all necessary parameter. The rest are Linux filesystem permission you should already aware to handle it :wink:

1 Like

I found out, that the gsad services are still running after “systemctl stop gsad” so you have to kill them by hand, otherwise you can change the configuration in “/etc/systemd/system/gsad.service”.

To solve the problem and be also flexible with a modern and fast webservice i used the reverse proxy solution with nginx.

It did the following:

CERTBOT / LET’S ENCRYPT

apt instal certbot -y

certbot certonly --server https://acme-v02.api.letsencrypt.org/directory --manual --preferred-challenges dns --email “email@domain.com” --agree-tos --no-eff-email --must-staple --redirect --hsts --uir --staple-ocsp --rsa-key-size 4096 --domain sub.domain.com

GSAD

→ kill all gsad processes

systemctl disable gsad

→ edit this file:

/etc/systemd/system/gsad.service

→ edit this line (add this there: --listen=127.0.0.1 --port=4000 --http-only)

ExecStart=/opt/gvm/sbin/gsad --drop-privileges=gvm --listen=127.0.0.1 --port=4000 --http-only

→ enable service and restart

systemctl daemon-reload
systemctl enable gsad
systemctl start gsad

→ check if the port ist listening on localhost

netstat -tulpen | grep 4000
tcp 0 0 127.0.0.1:4000 0.0.0.0:* LISTEN 0 7446690 892953/gsad

NGINX

apt install nginx nginx-extras libnginx-mod-http-headers-more-filter -y

→ create dhparam

cd /etc/ssl/certs/
openssl dhparam -out dhparams.pem 4096

→ edit this file

/etc/nginx/nginx.conf

→ edit this lline

ssl_protocols TLSv1.3;

 server {
         server_name sub.domain.com;
         server_tokens off;
         more_set_headers "Server: webserver";
 
         listen 443 ssl http2;
         ssl_session_cache shared:le_nginx_SSL:1m;
         ssl_session_timeout 1440m;
         ssl_stapling on;
         ssl_stapling_verify on;
         resolver 8.8.8.8 8.8.4.4 valid=300s;
         resolver_timeout 5s;
         ssl_trusted_certificate /etc/letsencrypt/live/sub.domain.com/chain.pem;
 
         ssl_prefer_server_ciphers on;
         ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
 
         ssl_certificate /etc/letsencrypt/live/sub.domain.com/fullchain.pem;
         ssl_certificate_key /etc/letsencrypt/live/sub.domain.com/privkey.pem;
         ssl_dhparam /etc/ssl/certs/dhparam.pem;
 
         # Add headers to serve security related headers
         add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
         add_header X-Content-Type-Options nosniff;
         add_header X-XSS-Protection "1; mode=block";
         add_header X-Robots-Tag none;
         add_header X-Download-Options noopen;
         add_header X-Permitted-Cross-Domain-Policies none;
         add_header Referrer-Policy "same-origin" always;
 
         location / {
                 proxy_set_header   Host $http_host;
                 proxy_set_header   X-Real-IP $remote_addr;
                 proxy_set_header   REMOTE_HOST $remote_addr;
                 proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
                 proxy_set_header   X-FORWARDED-PROTOCOL $scheme;
                 proxy_pass http://localhost:4000;
     }
 }

→ nginx config test

nginx -t

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

→ manage nginx service

systemctl start nginx
systemctl restart nginx
systemctl status nginx

→ check if the ports are listening

netstat -tulpen | grep nginx
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 7490929 908916/nginx: maste
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 0 7490928 908916/nginx: maste

Sorry but this is not helping at all, you need to supply the Let´s encrypt certificates direct to the GSAd and you can spare the complete NGINX and SystemD voodoo. Please keep it stupid and simple.

Just supply GSAD with the Let´s encrypt private Key and Certificate that´s it.

-k, --ssl-private-key= Use as the private key for HTTPS
-c, --ssl-certificate= Use as the certificate for HTTPS

In many cased it would be:

“/etc/letsencrypt/live//cert.pem” for the certificate “-c”
“/etc/letsencrypt/live//privkey.pem” for the private key “-k”

3 Likes