what is the mapping between cert file, key file, pem file and ca file AND redis TLS parameters?-CodePudding

I am using below commands:

openssl req -new -newkey -keyout example.key

openssl dhparam -out example.pem

I submit the csr (also generated by openssl not shown above) file to CA which reply with a text file named sighned certificate. This text file has 4 sections each section starts with ----BEGIN CERTIFICATE---- and ends with -----END CERTIFICATE------

Does the first section map to ROOT CERTIFICATE? Does the third section map to INTERMEDIATE CERTIFICATE? What the last section maps to?

I also use keytool to generate keystore.jks file. What is jks file and why it is needed?

Now in redis TLS docs

tls-cert-file /path/to/redis.crt
tls-key-file /path/to/redis.key
tls-ca-cert-file /path/to/ca.crt
tls-dh-params-file /path/to/redis.dh

What files I use to plugin in above settings?

What is the difference between tls-cert-file and tls-ca-cert-file?

CodePudding user response：

Refer from redis-src/utils/gen-test-certs.sh:

#!/bin/bash
mkdir -p tests/tls
openssl genrsa -out tests/tls/ca.key 4096
openssl req \
    -x509 -new -nodes -sha256 \
    -key tests/tls/ca.key \
    -days 3650 \
    -subj '/O=Redis Test/CN=Certificate Authority' \
    -out tests/tls/ca.crt
openssl genrsa -out tests/tls/redis.key 2048
openssl req \
    -new -sha256 \
    -key tests/tls/redis.key \
    -subj '/O=Redis Test/CN=Server' | \
    openssl x509 \
        -req -sha256 \
        -CA tests/tls/ca.crt \
        -CAkey tests/tls/ca.key \
        -CAserial tests/tls/ca.txt \
        -CAcreateserial \
        -days 365 \
        -out tests/tls/redis.crt
openssl dhparam -out tests/tls/redis.dh 2048

You can use this script to generate redis.crt, redis.key, ca.crt and redis.dh.

CodePudding user response：

Most commonly in production setups, certificates and keys are issued by a trusted authority, eg LetsEncrypt. This will provide you with its public key, the CA file.

You can then ask the authority to issue you a TLS certificate and key for a particular component or domain name, eg used by APIs. This will result in these files, and there will be many cert key pairs in a real world backend platform:

A private key (a .key file)
A public key (a .crt file)

Together these files represent a public key infrastructure. Usage is very common in Docker and Kubernetes scenarios.

REDIS SCENARIO

To get your redis server running on a developer workstation, you can generate all 3 types of file using openssl. See this script of mine.

I would aim to avoid JKS files. They are a Java specific layer on top of the PKI and a less portable concept. You should not need it to get redis working over TLS. Similarly, DH is an advanced key exchange behaviour that I don't think you'll need.

CLIENT TRUST

The trickier part is client connections to redis. In production setups this will just work, since an authority such as LetsEncrypt is trusted by operating systems and technology stacks.

If using OpenSSL generated certs you will need to use the kind of techniques from my blog post to avoid cryptic errors. This might include use of keytool to get the Java runtime to trust the CA file (a certificate issuing authority for development).