Comments (19)
Hi ivanvaccari,
Can you post your nginx.conf file and explain how you mount it into the container.
On a server
level you can define ciphers like in this example: https://github.com/JonasAlfredsson/docker-nginx-certbot/blob/master/examples/example_server_multicert.conf
from docker-nginx-certbot.
Hi, this is is the nginx.config in use:
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# Basic Settings
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
client_max_body_size 16M;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL Settings. See https://ssl-config.mozilla.org/#server=nginx
##
ssl_protocols TLSv1.2 TLSv1.3; # Dropping SSLv3, ref: POODLE
ssl_prefer_server_ciphers on;
ssl_session_cache shared:le_nginx_SSL:10m;
ssl_session_timeout 1440m;
ssl_session_tickets off;
# Updated list: https://ssl-config.mozilla.org/#server=nginx
ssl_ciphers TLS_RSA_WITH_AES_128_GCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
##
# Logging Settings
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip Settings
##
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
}
The needed cipher is TLS_RSA_WITH_AES_128_GCM_SHA256 (https://ciphersuite.info/cs/TLS_RSA_WITH_AES_128_GCM_SHA256/)
The compose configuration used to launch the instance:
version: '3.7'
services:
nginx:
image: jonasal/nginx-certbot:5.0.1
volumes:
- ./nginx/maintenance:/var/www/maintenance
- ./nginx/maintenancemode:/etc/nginx/maintenancemode
- ./nginx/nginx.conf:/etc/nginx/nginx.conf # volume per config nginx
- ./nginx/templates:/etc/nginx/templates
- ./letsencrypt:/etc/letsencrypt # volume per certbot. Necessario solo se si usa immagine jonasal/nginx-certbot
ports:
- target: 80
published: 80
protocol: tcp
mode: host
- target: 443
published: 443
protocol: tcp
mode: host
environment:
- NGINX_HOST=***************
- CERTBOT_EMAIL=*****************
deploy:
replicas: 1
update_config:
parallelism: 1
delay: 10s
order: stop-first
from docker-nginx-certbot.
Well, if you look at the at the list of ciphers you listed:
ssl_ciphers TLS_RSA_WITH_AES_128_GCM_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
You see that none of the other alternatives have underscores in them. If you follow your link you also see the "openssl name" (AES128-GCM-SHA256
) listed just below the IANA name, so I think if you just replace TLS_RSA_WITH_AES_128_GCM_SHA256
with that it should work.
from docker-nginx-certbot.
Used all the names in various tentatives.
Currently the ssl_ciphers i'm using is
ssl_ciphers AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
And the value is correctly set in the container:
docker exec -it `docker ps | grep nginx-certbot | cut -d' ' -f1` cat /etc/nginx/nginx.conf | grep ssl_ciphers
shows:
ssl_ciphers AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
However it's not active (testing from a local cli):
$ openssl s_client -cipher AES128-GCM-SHA256 -connect HIDDEN:443 -tls1_2
CONNECTED(000001A8)
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 178 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1715843593
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
---
18260:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:../openssl-1.1.1q/ssl/record/rec_layer_s3.c:1543:SSL alert number 40
Neither ssllabs shows it.
Does the fact that the container uses openssl 3 have something that influences it?
from docker-nginx-certbot.
Did you restart or just reload the container after changing the config?
And does nginx say anything in the logs about any problems?
from docker-nginx-certbot.
Questions regarding how nginx interacts with openssl is probably better to ask in the parent container's GitHub since we just add some nice to have she'll scripts at startup and don't touch nginx at all.
from docker-nginx-certbot.
Did you restart or just reload the container after changing the config?
And does nginx say anything in the logs about any problems?
i'm using docker swarm to manage images, the command i usually use to force the reload is this:
docker service update default_stack_nginx --force
Actually i'm not 100% sure what it does, but it should restart the container because usually it creates/remove containers before creating new ones.
Palying around with other ciphers are reflected in the container, both ssllabs and the openssl-cli confirm the presence or absence of the changed ciphers
from docker-nginx-certbot.
If you see the config changed inside the container then I think it does a full restart of it, as is necessary with file mounts, so that is good.
The TLS_RSA_WITH_AES_128_GCM_SHA256 (AES128-GCM-SHA256) cipher suite is part of TLS1.2, and appears to be supported by OpenSSL v3, so I don't think that is the problem.
You don't happen to override something through the other configuration files here?
##
# Virtual Host Configs
##
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;
Then I would suggest you restart the container with the environment variable DEBUG=1
and look through the logs to see if Nginx says something about invalid ciphers.
from docker-nginx-certbot.
You don't happen to override something through the other configuration files here?
No overrides apparently. /etc/nginx/sites-enabled/
does not exists, and the content of /etc/nginx/conf.d/
is the following:
redirector is the default of the image, default.cnf is the following:
# maintenance mode
geo $geo_host {
# our vpn gateway
HIDDEN allowed;
# dynamic ips
include /etc/nginx/maintenancemode/geo_dyn.conf;
}
server {
server_name HIDDEN;
# maintenance mode
error_page 503 /var/www/maintenance/error503.html;
location /var/www/maintenance/error503.html {
alias /var/www/maintenance/error503.html;
}
# SocketIO. By default socketIo is managed by standalone mit-ray.
location /socket.io/ {
# maintenance mode
if (-f /etc/nginx/maintenancemode/maintmode$geo_host) {
return 503;
}
proxy_pass http://mit-ray:3100/socket.io/;
proxy_http_version 1.1;
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;
# dont cache anything
proxy_cache off;
#websocket
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection 'upgrade';
proxy_cache_bypass $http_upgrade;
}
# web server
location / {
# maintenance mode
if (-f /etc/nginx/maintenancemode/maintmode$geo_host) {
return 503;
}
proxy_pass http://prodocu:3000/;
proxy_http_version 1.1;
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;
# dont cache anything
proxy_cache off;
}
listen [::]:443 ssl ipv6only=on;
listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/HIDDEN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/HIDDEN/privkey.pem;
ssl_dhparam /etc/letsencrypt/dhparams/ssl-dhparams.pem;
}
I'll try DEBUG=1
(not now, i have some other work to do)
from docker-nginx-certbot.
Unless there is something in the log you should probably reach out to the Nginx community to potentially get answers from those who knows this program in more detail than me :)
from docker-nginx-certbot.
Then I would suggest you restart the container with the environment variable
DEBUG=1
and look through the logs to see if Nginx says something about invalid ciphers.
I feel a little bit stupid to ask this question: i have enabled the DEBUG=1 flag, also by adding the "debug" directive to the "error_log" (docs here https://nginx.org/en/docs/debugging_log.html) but... where i'm supposed to read this log?
The /var/log/nginx/error.log
pipes data to /dev/stderr
, and when i cat
it, it's initially empty.
Setting it to a standard file also does not log boot data, only requests errors.
Some ideas?
from docker-nginx-certbot.
The parent image forwards (by default) the logs to stdout and stderr so it can be handled by the Docker log collector.
I have not used Docker swarm, so I don't know how to get logs from such a setup, but docker logs <container>
should net you all output from a container running on your system.
from docker-nginx-certbot.
Docker swarm is just an alternative mode to orchestrate containers, but all the other options of docker ar still available.
Definitely, docker logs
with DEBUG=1 does not show anything about ciphers.
I'ts horrible to say it, but to make it work i've proxied the set of specific REST api used by that old system via a unencrypted http endpoint. The sysadmin of the remote system don't want to enable more modern ciphers on their system.
from docker-nginx-certbot.
This seems like a little bit unexpected behavior since OpenSSL defines it as being part of TLS1.2, but using the Mozilla generator your linked the cipher mentioned only show up on the OLD setting which defines all the other TLS versions as well.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
a last try could perhaps be to add these as well to see if it works?
While I think the remote system is in the wrong (and I sure hope they don't handle any sensitive data), you could point a "legacy" domain name to your old Nginx deployment and then just let it establish a connection with your new Nginx for this particular system.
from docker-nginx-certbot.
Also, I don't think this ciphser needs it, but you could also try to add the ssl_dhparam
and let my container generate it at boot and see if that makes Nginx happy.
from docker-nginx-certbot.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
a last try could perhaps be to add these as well to see if it works?
Already tried (was one of the first things i did), but it still only enable TLS>=1.2, probably due to this: openssl/openssl#13299 (comment)
Also tried to lower SECLEVEL as that message suggests, with no luck.
I'm stopping following this problem for now and maturate some other ideas/research
from docker-nginx-certbot.
Alright, you could also post this issue for the original Nginx container to see if someone have similar experiences: https://github.com/nginxinc/docker-nginx
from docker-nginx-certbot.
Fyi: this solved the issue: nginxinc/docker-nginx#893
Quick solution: AES128-GMC-SHA256 requires a rsa key-based ssl certificate to be enabled:
From openssl ciphers -v
:
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
but the certificate generated by docker.nginx-certbot is ECDSA-based. I have deleted the previous certificate and set USE_ECDSA=0
to let the image regenerate a certificate with RSA key and now nginx also load the needed cipher.
from docker-nginx-certbot.
Thank you for returning with the answer here, today I learned something as well!
In the linked issue they mention dual certificates, and we actually have an example here if you are interested: https://github.com/JonasAlfredsson/docker-nginx-certbot/blob/master/examples/example_server_multicert.conf
from docker-nginx-certbot.
Related Issues (20)
- adding additional info in the http directive HOT 5
- How to add a wildcard SAN to a certificate of a domain? HOT 2
- Error when running service 'Important file(s) for '/etc/nginx/conf.d/default.conf' are missing or empty' HOT 3
- map variable for server_name HOT 2
- How to create certificates? HOT 7
- Any kind of subdomain HOT 7
- how to use subdomain wildcard? HOT 4
- How to set second default_server? HOT 4
- Unable to renew certificates HOT 4
- How can i define a renew hook in docker-compose environment? HOT 3
- Medium CVEs present on latest image CVE-2023-42363/6 HOT 2
- How to add new config in running container? HOT 2
- Avoid redirecting http -> https? HOT 2
- Consider using Freenginx HOT 6
- Expired certificate is not being replaced anymore HOT 6
- Add a way to automatically delete old, unused certificates HOT 2
- Flood? HOT 3
- Default Server HOT 2
- Certificate Authority failed to download the temporary challenge files created by Certbot HOT 9
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-nginx-certbot.