Se usi lets encrypt con certbot ti aggiorna la configurazione nginx con i parametri corretti e raggiungi questo risultato:

https://nimb.ws/lc3AnZ

esempio di utilizzo di certbot:

sudo add-apt-repository ppa:certbot/certbot
sudo apt install python-certbot-nginx
sudo certbot --nginx -d cliente.tuodominio.it

e, come dicevo, aggiunge automaticamente alla configurazione questi parametri:

include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
ssl_certificate /etc/letsencrypt/live/cliente.tuodominio.it/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/cliente.tuodominio.it/privkey.pem; # managed by Certbot

Buona parte delle risposte te le ha fornite @roberto. ssllabs non misura la sicurezza del server e/o di odoo ma semplicemente la bonta' dell'implementazione di SSL pertanto buona parte (tutto in questo caso) delle configurazioni vanno fatte sul proxy (nginx, apache, envoy o quello che preferisci) che gestisce SSL (do per scontato che non servi SSL direttamente con odoo :D).

Per ottenere un rank elevato (A, A+) devi disabilitare i vecchi protocolli, generare specifici DHPARAM etc etc ... nel rapporto di ssllab trovi le indicazioni.

Questo pero' non rende automaticamente odoo sicuro ... la "sicurezza" prevede deploy di proxy ed odoo su macchine differenti con quest'ultimo non esposto direttamente sulla rete pubblica, filtri per le url piu' a rischio quali ad esempio il database_manager e/o restrizioni per l'accesso alle url del backend e molte altre cose che non sempre sono attuabili senza una modifica del codice base.

Se il tuo cliente si accontenta del semplice test ssllab con le opportune configurazioni del proxy risolvi tutto.

Prendo spunto da questa domanda per estenderla ... voi come affrontate il problema della sicurezza???

Si esatto come ti ho indicato nella chat di telegram, il blocco di codice di qui sotto restringe i ciphers to nginx a quelli ritenuti più sicuri, inoltre è sempre meglio generare anche il DH (ssl_dhparam) per la negoziazione dei protocolli di encryption più sofisticati e di gran lunga più sicuri, quelli con ECDHE_XXXX (Elliptic-Curve Diffie Helmann), che è anche il motivo per cui sono elencati per primi per avere priorità sugli altri. Così come l'ssl_stapling consente di utilizzare l'OSCP (Online Status Certificate Protocol) per migliorare la sicurezza per l'autenticazione del certificato tramite l'autorità certificante.

Un primo tentativo è fare questa modifica :

 # It is *strongly* recommended to generate unique DH parameters

 # Generate them with: openssl dhparam -out /etc/nginx/dhparams_2048.pem 2048

 ssl_dhparam "/etc/nginx/dhparams_2048.pem";

 ssl_session_timeout  10m;

 ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

 ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

 ssl_prefer_server_ciphers on;

 ssl_stapling on;

 ssl_stapling_verify on;

 ssl_trusted_certificate "/etc/letsencrypt/live/x.x.x.x.x/fullchain.pem";

 resolver 8.8.8.8 8.8.4.4 valid=86400s;

 resolver_timeout 5s;

 add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload";  

 add_header X-Frame-Options ALLOWALL;  

 add_header X-Content-Type-Options nosniff;