Question 121220 in Redis Question posted in
The official documentation can be found here.

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

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?

Tags:

2

Answers


  1. 0

    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.

    Login or Signup to reply.
  2. 0

    CSR RESPONSE DATA

    If you have 4 files returned from the certificate signing request, then I would expect them to be as follows,

    • Root CA public key (root.crt)
    • Intermediate CA public key (intermediate.crt)
    • Certificate public key (public.crt)
    • Certificate private key (private.key)

    The first 3 of these should have this format, representing a public key:

    -----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIJAN7ZkzJkHq8DMA0GCSqGSIb3DQEBCwUAMCsxKTAnBgNV
BAMTIFNlbGYgU2lnb...
-----END CERTIFICATE-----

    I would expect the 4th file to have a different format, representing a private key:

    -----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAnLLaBhMIKAjaeLiY8qrr2xbTI5RRDK0QVyoogv3Bebv6llGj
pwnNmIOpMg/a33skE1YY78beAq5WSag3lv/hFGNTXTGs7Y4vZRjL92KrSkZWC/Cc
6YlkDR5+6nkIcTpiSShDxfF4a4qozgV1QNkXn4Cp4G6um798Tr6aZRI1wWohAvLp
B1O09IraZVhLLk
-----END RSA PRIVATE KEY-----

    For each public key, paste them into the GoDaddy online certificate viewer. The output text will enable you to distinguish between the role of each certificate, to ensure that you’ve identified them correctly.

    APPLY CERTIFICATE FILES TO REDIS

    Then assign values for redis as follows. The tls-cert-file is exposed to redis clients, to represent the public part of the redis server’s TLS identity. The tls-ca-cert-file is also exposed to clients, and represents the public part of the TLS identity for issuing authorities:

    tls-cert-file = public.crt
tls-key-file = private.key
tls-ca-cert-file = trusted.crt

    The trusted.crt file is a bundle file consisting of root and intermediate certificate authorities. It is formed by concatenating the root public key followed by the intermediate public key:

    -----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIJAN7ZkzJkHq8DMA0GCSqGSIb3DQEBCwUAMCsxKTAnBgNV
BAMTIFNlbGYgU2lnb...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDjzCCAnegAwIBAgIUY0Or/jjq9tZav7mle1DOWyyomPUwDQYJKoZIhvcNAQEL
BQAwMTEvMC0GA1UEAxMmU2VsZiBTaWduZWQgQ0EgZm9yIGF1dGhzYW1wbGVzLWRl
di5jb20wHhcNMjIwMzE3M...
-----END CERTIFICATE-----

    CERTIFICATE CREATION

    Sometimes it can be useful to create your own development certificates, to better understand the process, without requiring infrastructure. You can generate all 3 types of file using openssl. See this script of mine for an example.

    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, dhparams is a more advanced option used for key agreement between client and server. You should not need this if you just want to secure redis via TLS.

    CERTIFICATE TRUST

    You also need to manage client connections to redis. They will need to trust the root and intermediate certificates also, but the exact way you configure this will depend on the technology stack of the client.

    Trust can be established by either trusting the trusted.ca.crt file, or trusting both the root.crt and intermediate.crt files. My blog post has some examples of configuring trust in clients.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search