My current cerbot version running is:
certbot --version
certbot 0.27.1
My ngnix has TLS v1.0 but I do not want that running anymore:
cat /etc/letsencrypt/options-ssl-nginx.conf
# This file contains important security parameters. If you modify this file
# manually, Certbot will be unable to automatically provide future security
# updates. Instead, Certbot will print and log an error message with a path to
# the up-to-date file that you will need to refer to when manually updating
# this file.
ssl_session_cache shared:le_nginx_SSL:1m;
ssl_session_timeout 1440m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";
These are managed by certbot as seen and after some reseach I see that the latest version of certbot dont have tls v1.0
now I do not know how to update the certbot version.. need help
Certbot uses a configuration file to keep track of all the settings it uses, or at very least a record of the non-default ones. See here for information on that. However, updating certbot itself might be enough as I believe recent versions have been disabling 1.0 and 1.1 by default.
Honestly, I would also remove TLS 1.1 as well, which also has known issues. 1.2 is still safe. The only reason not to would be if clients are still using 1.1, which by now is fairly low of a chance. In fact, all major browsers are dropping support for 1.0 and 1.1 entirely. Support for TLS 1.2 was out in browsers ~2013, so the chances of you needing to support it are not that great.
Also, I always refer to this site which is periodically updated with recommended security configurations. Even their intermediate configuration recommends a minimum of TLS 1.2.
Related
We have k8s-cluster with ingress-controller (nginx version: nginx/1.17.8, ingress: rke2-ingress-nginx:1.36.301) - 4 replicas (one per worker)
To improve performance and be able to reuse the session between many replicas, I try to activate the ssl_session_cache & tickets.
ingress-configmap have following data-Block:
ssl-session-cache-size: 100m
ssl-session-tickets: "true"
ssl-session-timeout: 1440m
ssl-protocols: "TLSv1.2"
ssl-session-ticket-key: "RESULT OF openssl rand 80 | openssl enc -A -base64"
When i decrease replica count to 1, i get correct handshake and i can reuse the ticket in further requests without handshake.
When i increase the replicas count to > 1, and send the session ticket in second (third, fourth...) request (round-robin), i'm getting each time a new ticket from the server incl. full handshake. So session resumption doesn't work.
Configmap auto-update is working, each replica have the same nginx.conf and all the replicas have the same /etc/nginx/tickets.key
Ingress-controller-pod logs have no issues while updating the configmap:
I0929 13:56:50.165135 8 controller.go:137] Configuration changes detected, backend reload required.
I0929 13:56:50.267572 8 controller.go:153] Backend successfully reloaded.
Restarting all ingress-pods after updating the configmap also doesn't help.
Result of the configmap in nginx.conf:
ssl_protocols TLSv1.2;
ssl_early_data off;
# turn on session caching to drastically improve performance
ssl_session_cache builtin:1000 shared:SSL:100m;
ssl_session_timeout 1440m;
# allow configuring ssl session tickets
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/tickets.key;
Thanks!
I am using certbot with nginx plugin. Where I started with main.domain.com then I added subdomain.domain.com Whenever I issue certbot certificate the later is not displayed. I don't see a folder for subdomain at /etc/letsencrypt/live as well. But out of thin air the configuration it works like charm.
The issue is, I am getting a renewal due warning from certbot. Of course no entry at /etc/letsencrypt/renewal too.
What do I do now ?
I'm trying to figure out how to use the Porkbun Let's Encrypt Files with Nginx.
They have generated a zip file with the following files for me to use
domain.cert.pem, intermediate.cert.pem, private.key.pem, public.key.pem
From this site https://wbxpress.net/install-porkbun-ssl-nginx-wordpress/
I've worked out that
ssl_certificate is domain.cert.pem
ssl_certificate_key is private.cert.pem
But for my needs I have to specify the ssl_trusted_certificate as well.
Can anybody point me in the right direction ?
If you used the certbot you will get these files: README cert.pem chain.pem fullchain.pem privkey.pem
ssl_certificate should point to fullchain.pem
ssl_certificate_key should point to privkey.pem
ssl_trusted_certificate should point to chain.pem
From what I see, the PorkBun generated files are just renamed and mapped like this:
fullchain.pem -> domain.cert.pem
privkey.pem -> private.key.pem
chain.pem -> intermediate.cert.pem
cert.pem -> public.key.pem
So you would do this for the files given by PorkBun:
ssl_certificate should point to domain.cert.pem
ssl_certificate_key should point to private.key.pem
ssl_trusted_certificate should point to intermediate.cert.pem
Basically fullchain.pem is just made up of cert.pem + chain.pem concatenated together. See here for more information: Generate CRT & KEY ssl files from Let's Encrypt from scratch
Personally, I would not use their generated ones because you would have to manually replace it every 90 days. Best if you use another option like certbot which lets you automatically renew it or do it 'manually' via some cronjob. Good luck!
Please help me with nginx configuration on Windows for use TLS connections based on PKCS#11 engine.
I have driver pkcs11 (C:\nCipher\nfast\toolkits\pkcs11\cknfast-64.dll) from provider.
My nginx.conf file looks like:
worker_processes 1;
events {
worker_connections 1024;
}
#nShield PKCS#11
ssl_engine pkcs11;
http {
...
server {
listen 8888;
server_name localhost;
return 301 https://$server_name$request_uri;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name localhost;
ssl_certificate C:/nginx-1.16.1/ssl/test_selfcert;
ssl_certificate_key "engine:pkcs11:pkcs11:token=ocs2;object=test_key";
ssl_session_cache shared:SSL:1m;
ssl_session_timeout 5m;
ssl_ciphers TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:ECDHE:!COMPLEMENTOFDEFAULT;
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
location / {
proxy_pass http://localhost:9999/;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port $server_port;
}
}
}
I tried to check this config and get error:
>nginx -t
nginx: [emerg] ENGINE_by_id("pkcs11") failed (SSL: error:25078067:DSO support routines:win32_load:could not load the shared library:filename(Z:\nginx\nginx-stab
le\objs.msvc8\lib\openssl-1.1.1c\openssl\lib\engines-1_1\pkcs11.dll) error:25070067:DSO support routines:DSO_load:could not load the shared library error:260B60
84:engine routines:dynamic_load:dso not found error:2606A074:engine routines:ENGINE_by_id:no such engine:id=pkcs11)
nginx: configuration file C:\nginx-1.16.1/conf/nginx.conf test failed
I think there is an error in my openssl configuration because I did not define the pkcs11 driver there.
At the end of the default configuration C:\nCipher\nfast\lib\ssleay\openssl.cnf I added a block like:
...
openssl_conf = openssl_def
[openssl_def]
engines = engine_section
[engine_section]
chil = chil_section
[chil_section]
SO_PATH=c:\\Program Files (x86)\\nCipher\\nfast\\toolkits\\hwcrhk\\nfhwcrhk.dll
#added
[engine_section]
pkcs11 = pkcs11_section
[pkcs11_section]
engine_id = pkcs11
dynamic_path = "C:\\Program Files\\OpenSSLx64\\bin\\pkcs11openssl64x.dll"
MODULE_PATH = "C:\\nCipher\\nfast\\toolkits\\pkcs11\\cknfast-64.dll"
init = 0
...
But file pkcs11openssl64x.dll is NOT exist on my computer! In 'dynamic_path' param I tried to download and use files libpkcs11-helper-1.dll, onepin-opensc-pkcs11.dll, opensc_pkcs11.ddl , but all of them not working. When I tried to use this configuration without 'dynamic_path' param, i get error:
> openssl engine -t -c pkcs11
13112:error:25078067:DSO support routines:WIN32_LOAD:could not load the shared library:dso_win32.c:179:filename(C:\Program Files\Git\mingw64\lib\engines\pkcs11.
dll)
13112:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
13112:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:
13112:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:411:id=pkcs11
or with use config path:
> openssl engine -t -c pkcs11 -config "C:\nCipher\nfast\lib\ssleay\openssl.cnf"
13572:error:25078067:DSO support routines:WIN32_LOAD:could not load the shared
library:./crypto/dso/dso_win32.c:179:filename(C:\nCipher\nfast\bin\pkcs11.dll)
13572:error:25070067:DSO support routines:DSO_load:could not load the shared library:./crypto/dso/dso_lib.c:233:
13572:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:./crypto/engine/eng_dyn.c:467:
13572:error:2606A074:engine routines:ENGINE_by_id:no such engine:./crypto/engine/eng_list.c:391:id=pkcs11
13572:error:25078067:DSO support routines:WIN32_LOAD:could not load the shared library:./crypto/dso/dso_win32.c:179:filename(C:\nCipher\nfast\bin\-config.dll)
13572:error:25070067:DSO support routines:DSO_load:could not load the shared library:./crypto/dso/dso_lib.c:233:
13572:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:./crypto/engine/eng_dyn.c:467:
13572:error:2606A074:engine routines:ENGINE_by_id:no such engine:./crypto/engine/eng_list.c:391:id=-config
13572:error:25078067:DSO support routines:WIN32_LOAD:could not load the shared library:./crypto/dso/dso_win32.c:179:filename(C:\nCipher\nfast\lib\ssleay\\openss
l.cnf)
13572:error:25070067:DSO support routines:DSO_load:could not load the shared library:./crypto/dso/dso_lib.c:233:
13572:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:./crypto/engine/eng_dyn.c:467:
13572:error:2606A074:engine routines:ENGINE_by_id:no such engine:./crypto/engine/eng_list.c:391:id=C:\nCipher\nfast\lib\ssleay\openssl.cnf
But I'm expecting the next:
> openssl engine -t -c pkcs11
(pkcs11) pkcs11 engine
[RSA, rsaEncryption, id-ecPublicKey]
[ available ]
Also no pkcs#11 driver are detected when outputting:
>openssl engine -t -c
(dynamic) Dynamic engine loading support
[ unavailable ]
(chil) CHIL hardware engine support
[RSA, DH, RAND]
[ available ]
Please help me to set the correct configuration for NGINX to work with TLS connection setup.
It looks like you are missing the P11 engine library; see this answer for how you might get it for Windows: https://stackoverflow.com/a/58287898/7369488
On Linux platforms that component is normally available through the distribution repository, which means a considerably easier setup of nginx.
For help with nShield devices meanwhile visit: https://nshieldsupport.entrust.com/
I assume you have an nCipher HSM? Which version of security world software are you running? The PKCS#11 dlls should have been on the install ISO. Have you already created a Security World?
Your configuration is trying to use both the CHIL engine and PKCS#11. These are two different APIs for talking to Hardserver, pick one but not both.
When I try to start the nginx server with this configuration I get an error
nginx: [emerg] no ssl_client_certificate for ssl_client_verify
My Configuration looks like
# HTTPS server
server {
listen 4443;
server_name localhost;
ssl on;
ssl_certificate /home/user/conf/ssl/server.pem;
ssl_certificate_key /home/user/conf/ssl/server.pem;
ssl_protocols TLSv1.2;
ssl_verify_client optional;
ssl_trusted_certificate /home/user/ssl/certs/certificate_bundle.pem;
include conf.d/api_proxy.conf;
}
As per the error, I should use ssl_client_certificate directive but as per the documentation if I don't want to send the list of certificates to clients I should use ssl_trusted_certificate.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_client_certificate
Can someone help me figure out what am I missing?
The answer is in the error message itself:
nginx: [emerg] no ssl_client_certificate for ssl_client_verify
If you disable ssl_client_verify in your configuration, the error will disappear upon the next start of nginx. It appears that the semantics of ssl_trusted_certificate only pertain to its exclusive use and is subject to "logical override" when other configuration directives are in play.
I would personally prefer enabling ssl_client_verify to mean: "client certificates are verified if presented; clients are given no information regarding what client certificates or authorities are trusted by the web server". But, I can also see advantage in troubleshooting TLS handshakes when this information is available. From a security perspective, I only see metadata presented to the client via openssl s_client; there is no public key or other "signature-critical" information that a malicious client could use to, for example, attempt to clone/reconstruct the CA.
For example, running the following against a local instance of nginx with your configuration:
openssl s_client -key client.key -cert client.crt -connect localhost:443
... would show data similar in structure to the following in the response:
Acceptable client certificate CA names
/CN=user/OU=Clients/O=Company/C=Location
Client Certificate Types: RSA sign, DSA sign, ECDSA sign
Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Shared Requested Signature Algorithms: RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
In my opinion, the value of the above is confined in value to troubleshooting.
Your DN structures are (ideally) not "security relevant" (especially if the context is an Internet-facing web service).