Recommended TLS Ciphers for Traefik - ssl

I'm looking for a recommended configuration for SSL/TLS in Traefik. I have set minVersion = "VersionTLS12" to avoid the weaker older versions and found the supported ciphers in Go. Cross-checking that with the recommendations from SSLLabs I came up with the following sequence (order matters):
cipherSuites = [
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
]
[Update] Later cross-checked with Mozilla's SSL Config Generator, dropping the SHA-1 ones and using the suggested order:
cipherSuites = [
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
]
Does that make sense? I want to avoid weak ciphers, but include as many strong ciphers as possible for compatibility.

You can use this page to generate your traefik config: https://ssl-config.mozilla.org/#server=traefik&server-version=1.7.12&config=intermediate
# generated 2019-07-17, https://ssl-config.mozilla.org/#server=traefik&server-version=1.7.12&config=intermediate
defaultEntryPoints = ["http", "https"]
[entryPoints]
[entryPoints.http]
address = ":80"
[entryPoints.http.redirect]
entryPoint = "https"
[entryPoints.https]
address = ":443"
[entryPoints.https.tls]
minVersion = "VersionTLS12"
cipherSuites = [
"TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256",
"TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256",
"TLS_DHE_RSA_WITH_AES_256_GCM_SHA384",
"TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"
]
[[entryPoints.https.tls.certificates]]
certFile = "/path/to/signed_cert_plus_intermediates"
keyFile = "/path/to/private_key"

Edit: as noted in the issue linked below, the config-generator has been fixed.
I found this question while researching the cipher suites for Traefik. So, for future reference, and people who have tried the generator but ran into problems:
I found the ssl-config page of Mozilla, that Rui Martins mentioned as well. This works fine, except for the last four entries.
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Are not recognized by Traefik as valid cipher suites.
I checked the Go documentation, and found that the cipher suites aren't mentioned there either. Relatively close alternatives were mentioned however: https://godoc.org/crypto/tls#pkg-constants
So I replaced the values as follows:
+-----------------------------------------------+----------------------------------------+
| Old Value | New Value |
+-----------------------------------------------+----------------------------------------+
| TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 | ‎TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305 |
+-----------------------------------------------+----------------------------------------+
| TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305 |
+-----------------------------------------------+----------------------------------------+
| TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 |
+-----------------------------------------------+----------------------------------------+
| TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 |
+-----------------------------------------------+----------------------------------------+
Note the removed _SHA256 for the first two entries, and the added EC for the last two.
This works fine, but is not a solution for the core problem. As I do not have a lot of knowledge or experience in cipher suites, I have filed a bug report with Mozilla about their ssl-config generation for Traefik. ( https://github.com/mozilla/ssl-config-generator/issues/52 )

Looks good. I'm running the same config as in your update and everything looks secure and compatible according to the SSL Labs tests.
Update 05-07-19:
The CBC ciphers are now also weak according to SSL Labs. You can remove these, but if your certificate is signed with RSA you won't be able to view your website on IE 11 with Windows 7. I signed my certificate with ECDSA with the current ciphers above (wihout CBC) to get it working on IE 11 Windows 7.

Related

Unable to decrypt TLS 1.3 packets with the keys got using SSL_CTX_set_keylog_callback openssl API in Wireshark

I'm working on a task where i need to decrypt all the TLS 1.3 encrypted packets in wireshark (using Edit->Preferences->Protocol->TLS->pre-Master_secret log filename option) for debugging purpose. so i stored all the keys of TLS 1.3 sessions by setting the call back function with openssl provided API() call back function into a file as shown below:
SSL_CTX_set_keylog_callback(pCtx_m,Keylog_cb_func);
void Keylog_cb_func(const SSL *ssl, const char *line) {
// Code to log the line into a file in append mode
}
With this, i'm able to decrypt the TLS 1.3 packets with the keys logged into the file for only the below three ciphers in wireshark
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
and the other two ciphers of TLS1.3 TLS_AES_128_CCM_8_SHA256 , TLS_AES_128_CCM_SHA256 is not getting decrypted using the keys (in wireshark) opensll API has given though the calls are established over these two ciphers successfully.
I have read this post in stackoverflow about the default enabled cipher suite but i'm not quite sure about if this issue is something related to that. Could anyone help me to understand what i'm doing wrong here:
Sample Key File:
SERVER_HANDSHAKE_TRAFFIC_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 aa48ffe195090f87138caf32a520ecd41644f23f6d778f6436b5e2d697452572
CLIENT_HANDSHAKE_TRAFFIC_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 415e363721b8e204d3e2a2f94682d25792f565770a0f9221e86738d1c540e21b
EXPORTER_SECRET dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 25276ba5f066f69b6caac00d35e981ff0b7d70e20d541c9435538d32a640ecdc
SERVER_TRAFFIC_SECRET_0 dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 9d683bacbb0ce07fa5d0425c2763920f11d98af85c7461a52e26efb6bdaf74b5
CLIENT_TRAFFIC_SECRET_0 dd228de6d3f32ae5d83a9009c2e5908cb71c16d8624f5930dd05cabea3b7cc63 bfca7bc330de3836b0e49619375b504f4d2794206c4ecc7fcd1dfdab363bd36a
SERVER_HANDSHAKE_TRAFFIC_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 1be3cc095c1e336168ab10619c266eaf7a9057edf724d65f3016ba64d642ab0f
EXPORTER_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 0cfa53e94a8a6cf085af19a45a062152299b5ccea84cbffe237f136f0854672e
SERVER_TRAFFIC_SECRET_0 cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 7de206865a34e1b3b004d47075d534ebfd60b47a16ce525f3c0da47c9c78c57f
CLIENT_HANDSHAKE_TRAFFIC_SECRET cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 1a4cad91d84607f44cd6a65cf1e9bcddaf3488d2dcb67b5246995485226dfa5c
CLIENT_TRAFFIC_SECRET_0 cb2136f271de0e168eb92a9f2a6811c76fe87d08c9b4ae374f4efc72ccdc7ea5 be0df5b77fb5edb1785118e6adb119a5820beacb74d01d8cdee344d3feb56488
Wireshark Version: Version 3.6.1 (v3.6.1-0-ga0a473c7c1ba).
Thanks in advance
Prakash
It's found that wireshark Version 3.6.7 (v3.6.7-0-g4a304d7ec222) itself currently has an issue in the TLS 1.3 packet decryption feature for these two ciphers (LS1.3 TLS_AES_128_CCM_8_SHA256 , TLS_AES_128_CCM_SHA256 ) due to invalid-aad-length, and the same would be fixed in the upcoming version. We have reported a bug to the wirshark forum as in the link below
https://gitlab.com/wireshark/wireshark/-/issues/18277

Cowboy Webserver using HTTP2 and TLS getting ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY in Chrome

I'm using: Erlang OTP 21 and Cowboy 2.4
Code:
cowboy:start_tls(
my_listener,
[
{port, Web_Server_Port},
{certfile, Cert_File},
{keyfile, Key_File}
],
#{env => #{dispatch => dispatcher()}}
)
I'm using this to start the web server, which work fine on HTTP1.1,but now Chrome is using HTTP2 and that can't be disabled.
So now I'm receiving:
ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY
I also experience a similar problem Firefox with HTTP2 enable:
Error code: NS_ERROR_NET_INADEQUATE_SECURITY
but on Firefox I can disable HTTP2. It work fine when HTTP2 is disabled.
I have verified my certificate is good and I get the green lock under HTTP1.1
I have read that HTTP2 is stricter with the ciphers that are used and the order they appear.
Fixing ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY SSL error in Chrome
https://www.jeffgeerling.com/blog/2016/fixing-errspdyinadequatetransportsecurity-ssl-error-chrome
But not sure if that is the problem.
I'm not sure of what ciphers to use also not exactly sure how to indicate their use in cowboy. I have tried adding a cipher option in the options, but this doesn't correct the problem:
{ciphers, [
{ecdhe_ecdsa,aes_256_cbc,sha384,sha384},
{ecdhe_rsa,aes_256_cbc,sha384,sha384},
{ecdh_ecdsa,aes_256_cbc,sha384,sha384},
{ecdh_rsa,aes_256_cbc,sha384,sha384},
{dhe_rsa,aes_256_cbc,sha256},
{dhe_dss,aes_256_cbc,sha256},
{ecdhe_ecdsa,aes_256_cbc,sha},
{ecdhe_rsa,aes_256_cbc,sha},
{dhe_rsa,aes_256_cbc,sha},
{dhe_dss,aes_256_cbc,sha},
{ecdh_ecdsa,aes_256_cbc,sha},
{ecdh_rsa,aes_256_cbc,sha},
{ecdhe_rsa,aes_128_cbc,sha},
{dhe_rsa,aes_128_cbc,sha},
{dhe_dss,aes_128_cbc,sha},
{ecdh_ecdsa,aes_128_cbc,sha},
{ecdh_rsa,aes_128_cbc,sha}
]}
Any suggestions on what I'm doing wrong here?
HTTP/2 forbids the use of old ciphers including all the CBC ciphers you have listed.
Enable some GCM ciphers like this, which should be accepted by most browsers:
{ciphers, ["ECDHE-RSA-AES256-GCM-SHA384"]}
Though by default it should allow these.
See here for more information: http://ezgr.net/increasing-security-erlang-ssl-cowboy/

Is it possible to configure cipher suites used by RabbitMQ Management Plugin?

I have an instance of RabbitMQ 3.7.7-management image running. It has the rabbitmq-management plugin enabled and configured to use HTTPS as per the documentation:
management.listener.port = 15671
management.listener.ssl = true
management.listener.ssl_opts.cacertfile = /path/to/cacert.pem
management.listener.ssl_opts.certfile = /path/to/cert.pem
management.listener.ssl_opts.keyfile = /path/to/key.pem
management.listener.ssl_opts.fail_if_no_peer_cert = false
management.listener.ssl_opts.versions.1 = tlsv1.2
When I evaluate the TLS setup with testssl.sh testing tool, a test for SWEET32 vulnerability fails:
Testing vulnerabilities
...
SWEET32 (CVE-2016-2183, CVE-2016-6329) VULNERABLE, uses 64 bit block ciphers
...
OpenVAS framework also complains:
Vulnerability Detection Result
'Vulnerable' cipher suites accepted by this service via the TLSv1.2 protocol:
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
TLS_RSA_WITH_3DES_EDE_CBC_SHA (SWEET32)
Solution type: Mitigation
The configuration of this services should be changed so that it does not accept the listed cipher suites anymore.
Is it possible to configure what cipher suites will be used by the RabbitMQ Management Plugin? For RabbitMQ it is possible, but looking at rabbitmq_management.schema it seems that for the Management Plugin it's impossible. Or is there a different way to fix the vulnerability?
You will have to use the advanced.config file to do so. I'm assuming that you have already created /etc/rabbitmq/rabbitmq.conf with the settings you show. Create the /etc/rabbitmq/advanced.config file with these contents and re-start RabbitMQ:
[
{rabbitmq_management, [
{listener, [
{ssl_opts, [
{ciphers, [
%% CIPHERS GO HERE
]}
]}
]}
]}
].
The setting should be merged into what is specified in rabbitmq.conf. You can check the generated config files in /var/lib/rabbitmq/...
If this does not work, please follow up on the mailing list.
NOTE: the RabbitMQ team monitors the rabbitmq-users mailing list and only sometimes answers questions on StackOverflow.

How does one specify a particular cipher suite for a nginx docker instance?

I am running a newly built discourse docker image on Google Compute Engine. I converted that to use https using letsencrypt following the walk through and I get an A+ rating from ssllabs. However the scripting agent I'm using doesn't support either of the two TLS 1.0 cipher suites enabled [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] and I'd like to add TLS-DHE-RSA-WITH-AES-256-CBC-SHA which is supported by the open source rebol3 fork ren-c.
I've modified my web.ssl.template.yml file from
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:\
ECDHE-RSA-AES256-SHA;
to
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:\
ECDHE-RSA-AES256-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
and rebuilt the app using
sudo ./launcher rebuild app
but this doesn't alter the cipher_suites available.
I'm now wondering if I have to alter the nginx.conf directly, wherever that is, instead of asking the discourse build script to do it ...
Changing the line in /var/discourse/templates/web.ssl.template.yml
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256$RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA;
to
ssl_ciphers 'HIGH:!aNULL:!MD5';
changes the supported TLS 1.0 suites to
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp384r1 (eq. 7680 bits RSA) FS 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp384r1 (eq. 7680 bits RSA) FS 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
and still gives an A+ rating from ssllabs.
mkdir -p containers/templates
cp templates/web.ssl.template.yml containers/templates
fuss with the file
add containers/templates/web.ssl.template.yml to you app.yml file in the templates section
profit

Cassandra nodes cannot see each other when internode encryption is enabled

I had set up a 6-node Cassandra cluster spanning two AWS regions / datacenters (3 in each) and everything was working fine. After getting that much working I attempted to enable internode encryption which I cannot get to work properly, despite reading innumerable documents on the subject and fiddling endlessly.
I don't see any errors or anything out of the ordinary in the logs. I do see the following line in the logs which indicates it has started the encrypted messaging service, as expected:
MessagingService.java:482 - Starting Encrypted Messaging Service on SSL port 7001
I have enabled verbose logging for SSL in cassandra-env.sh, however this does not produce any errors or additional information about SSL internode connections that I can see (update below):
JVM_OPTS="$JVM_OPTS -Djavax.net.debug=ssl"
I can connect to from one node to all the others on the encrypted messaging port 7001 using nc, so there's no firewall issue.
ubuntu#ip-5-6-7-8:~$ nc -v 1.2.3.4 7001
Connection to 1.2.3.4 7001 port [tcp/afs3-callback] succeeded!
I can connect to each node locally using cqlsh (I haven't enabled client-server encryption) and can query the system keyspace, etc.
However, if I run nodetool status I see that the nodes cannot see each other. Only the node that I'm querying the cluster on is present in the list. This was not the case before internode encryption was enabled, they could all see each other just fine then.
ubuntu#ip-5-6-7-8:~$ nodetool status
Datacenter: us-east_A
=====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
-- Address Load Tokens Owns Host ID Rack
UN 1.2.3.4 144.75 KB 256 ? 992ae1bc-77e4-4ab1-a18f-4db62bb0ce6f 1b
My process was this:
Created a certificate authority for my cluster
Created a keystore and truststore for each node and added my CA certificate chain to both
Generated a key pair and CSR for each node, signed it with my CA, and added the resulting certificate to each node's keystore
Updated each node's configuration as reads below
Restarted all nodes
The server encryption configuration I'm using is this, with the appropriate values in the $variables.
server_encryption_options:
internode_encryption: all
keystore: $keystore_path
keystore_password: $keystore_passwd
truststore: $truststore_path
truststore_password: $truststore_passwd
require_client_auth: true
protocol: TLS
algorithm: SunX509
store_type: JKS
cipher_suites: [TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA,TLS_DHE_RSA_WITH_AES_128_CBC_SHA,TLS_DHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA]
If anybody could offer some insight or a direction to look in it would be greatly appreciated.
Update: Cipher Suite Agreement
Apparently SSL debug logging prints to stdout, which is not logged to Cassandra's logfiles, so I didn't see that output before. Running Cassandra in the foreground I can see a ton of SSL errors tracing out, all of which complain of handshake failure, because:
javax.net.ssl.SSLHandshakeException: no cipher suites in common
In an attempt to solve this problem I have switched to the Oracle JRE (I was being lazy and using OpenJDK before) and installed the JCE unlimited strength cryptography policy files to ensure all possible ciphers would be supported.
It didn't fix anything.
This is especially confusing given that all these nodes are exactly identical: hardware, OS vendor and version, Java vendor and version, Cassandra version, and configuration file. I cannot imagine why they cannot agree on a cipher suite under these circumstances.
The following is the full error that is traced:
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1449074039 bytes = { 205, 93, 27, 38, 184, 219, 250, 8, 232, 46, 117, 84, 69, 53, 225, 16, 27, 31, 3, 7, 203, 16, 133, 156, 137, 231, 238, 39 }
Session ID: {}
Cipher Suites: [TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
%% Initialized: [Session-3, SSL_NULL_WITH_NULL_NULL]
%% Invalidated: [Session-3, SSL_NULL_WITH_NULL_NULL]
ACCEPT-/1.2.3.4, SEND TLSv1.2 ALERT: fatal, description = handshake_failure
ACCEPT-/1.2.3.4, WRITE: TLSv1.2 Alert, length = 2
ACCEPT-/1.2.3.4, called closeSocket()
ACCEPT-/1.2.3.4, handling exception: javax.net.ssl.SSLHandshakeException: no cipher suites in common
ACCEPT-/1.2.3.4, called close()
ACCEPT-/1.2.3.4, called closeInternal(true)
INFO 16:33:59 Waiting for gossip to settle before accepting client requests...
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
ACCEPT-/1.2.3.4, setSoTimeout(10000) called
ACCEPT-/1.2.3.4, READ: SSL v2, contentType = Handshake, translated length = 57
After a great deal more poking and prodding I've finally managed to get this to work. The problem was related to certificates and the keystore.
As a result of these problems the SSL handshake would fail either due to certificate chain problems or cipher suite agreement problems. Cassandra rather unhelpfully discards errors related to SSL and logs nothing.
In any case, I managed to get things working by doing the following:
Ensure that the CA generates node certificates with both client and server key usage attributes. Failing to include one or the other will prevent nodes from authenticating to each other properly. This presents itself as the cipher suite agreement error. If you're using OpenSSL to manage your CA, I've included the -extensions configuration I used below.
Ensure that both the root and any intermediate CA certificates you are using (if you're using an intermediary CA) are imported into both the keystore and truststore.
Ensure that the node certificate imported into the keystore includes the full trust chain from the primary certificate down to the CA root, including any intermediaries – even though you have already imported these CA certificates separately into the keystore. Failing to do this presents itself as an invalid certificate chain errors.
OpenSSL CA Config
Here's my extensions section for dual-role client/server certificates. You can include this in your OpenSSL config file and reference it when signing by specifying -extensions dual_cert.
[ dual_cert ]
# Extensions for dual-role user/server certificates (`man x509v3_config`).
basicConstraints = CA:FALSE
nsCertType = client, server
nsComment = "Client/Server Dual-role Certificate"
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid,issuer:always
keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = clientAuth, serverAuth
Creating a PEM containing the full trust chain
To create a single PEM file which contains the full trust chain for your node certificate, simply cat all the certificate files in reverse order from the node certificate down to the CA root.
cat node1.crt ca-intermediate.crt ca-root.crt > node1-full-chain.crt