Skip to main content

ERROR: Failed to get peer certificates for peer

What does this error mean?

This error means that an SSL peer was unable to be identified from the X509 certificates.

Why does this error occur?

During the SSL handshake process, an ordered array of peer X.509 certificates, with the peer's own certificate first followed by any certificate authorities is returned. If the peer was not able to identify itself (for example; no certificate, the particular cipher suite being used does not support authentication, or no peer authentication was established during SSL handshaking) an SSLPeerUnverifiedException exception is thrown and the error is logged.

How do you fix this error?

Verify that your certificates are configured properly and reload if necessary.

The following information comes from the DataStax SSL documentation. It will run you through setting up the certificates properly.

 

Perform the following steps on a dedicated CA server which is fully encrypted and permanently isolated from the network. When using BYO CA, always create the root pair for certificate signing in a secure environment. Anybody with access to the root CA files can use it to sign certificates.

Note: DataStax recommends using a computer outside the DSE environment to generate and manage SSL certificates.

The Common Name (CN) that is used to generate the SSL certificate must match the DNS resolvable host name. Mismatches between the CN and node hostname cause an exception and the connection is refused.

Procedure

Skip to step 3 when using a third-party signed certificate or when adding a node using an existing rootCA.

  1. BYO root CA only: create your own root CA for signing node certificates:
    1. Create a directory for the CA and then change to that directory: mkdir -p dse/root/ca
    2. cd dse/root/ca
      Note: Ensure that the root CA files created in these steps are secured on a fully isolated computer dedicated to CA certificate management.
    3. Create a configuration file in the ca directory: # gen_rootCa_cert.conf
    4. [ req ]
    5. distinguished_name = req_distinguished_name
    6. prompt = no
    7. output_password = myPass
    8. default_bits = 2048
    9.  
    10. [ req_distinguished_name ]
    11. C = US
    12. O = org_name
    13. OU = cluster_name
    14. CN = rootCa

      Where you define the variables for your environment as follows:
      • gen_rootCa_cert.conf is the configuration file name
      • myPass is the CA password
      • US is the two character country code
      • org_name is the name of your organization
      • cluster_name is the name of your DataStax Enterprise cluster
    15.  
    16. Create a root pair. openssl req -config gen_rootCa_cert.conf \
    17. -new -x509 -nodes \
    18. -subj /CN=rootCa/OU=cluster_name/O=DataStax/C=US/ \
    19. -keyout rootCa.key \
    20. -out rootCa.crt \
    21. -days 365

      The root pair, rootCa.key key file and rootCa.crt are created. These instructions are for development and test environments, for a production environment these files would be carefully secured as described in the OpenSSL documentation.
    22. Verify the root certificate: openssl x509 -in rootCa.crt -text -noout

      Certificate:
    23.     Data:
    24.         Version: 1 (0x0)
    25.         Serial Number: 14793138693831603662 (0xcd4bc943beeb35ce)
    26.     Signature Algorithm: sha256WithRSAEncryption
    27.         Issuer: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
    28.         Validity
    29.             Not Before: Jan 23 20:15:06 2017 GMT
    30.             Not After : Jan 23 20:15:06 2018 GMT
    31.         Subject: C=US, O=datastax, OU=pw-j-dse, CN=rootCa
    32.         Subject Public Key Info:
    33.             Public Key Algorithm: rsaEncryption
    34.                 Public-Key: (2048 bit)
    35.                 Modulus:
    36.                     00:d8:71:e0:51:07:ad:f1:f7:0b:4d:2c:10:4c:24:
    37.                     19:9f:1f:d4:2a:a1:a6:89:3d:e1:12:81:3b:4d:bd:
    38.                     2d:da:fb:9e:d5:c5:ba:ed:82:80:28:35:e5:00:86:
    39.                     96:2b:67:18:37:c9:80:32:3e:40:0a:25:5d:c2:d5:
    40.                     1c:bf:de:29:7a:fa:d6:32:20:35:39:03:e6:0a:35:
    41.                     96:9d:8e:ca:88:b2:71:24:50:d2:94:1c:80:de:dd:
    42.                     39:35:57:38:b2:09:39:ba:b3:9b:60:a1:5a:c7:f3:
    43.                     04:35:73:f9:b6:05:1e:09:a2:e1:0e:1c:eb:6f:5e:
    44.                     66:71:ec:38:08:99:6e:a3:d5:2a:0f:af:99:f5:19:
    45.                     c0:6d:4d:b0:ae:0f:6e:7b:c9:78:7d:29:37:3c:3d:
    46.                     38:7a:74:da:d1:16:38:5a:2b:f1:ac:a0:39:91:4a:
    47.                     83:6f:1e:92:b5:66:fd:7f:5f:57:77:5f:c5:c6:ca:
    48.                     23:63:95:d5:36:04:c2:c3:94:6f:2d:56:7e:96:4b:
    49.                     e1:f2:ca:cd:4a:d6:9d:50:1a:5d:6e:1b:76:57:b4:
    50.                     cd:a6:1a:6a:bb:82:d3:32:b4:b6:85:34:b1:d3:6c:
    51.                     31:f7:a1:51:2e:1f:48:c7:c9:04:d2:c4:38:d7:84:
    52.                     c8:cb:08:10:04:a8:a6:12:cf:48:54:88:b6:f7:bc:
    53.                     f2:5d
    54.                 Exponent: 65537 (0x10001)
    55.     Signature Algorithm: sha256WithRSAEncryption
    56.         43:8d:98:8c:d7:26:52:41:ad:de:c9:80:8d:4f:d6:6e:21:69:
    57.         81:7d:eb:af:93:6e:15:ad:9d:fe:ee:1a:60:d6:aa:92:86:a2:
    58.         fd:e1:8f:95:b9:ee:db:59:63:fd:cd:05:72:63:d6:6b:14:cf:
    59.         34:8c:15:cd:38:0a:ef:0d:41:de:9d:55:f2:2a:eb:1d:ca:44:
    60.         21:f8:18:41:42:d9:e2:fb:c4:97:80:9c:ac:8b:61:d8:d9:33:
    61.         38:9d:98:79:39:04:06:a8:b0:8e:e2:0e:49:5b:13:95:0b:42:
    62.         2f:64:8c:9d:4a:6e:84:ca:40:26:7e:c8:a2:f3:e0:09:fc:9c:
    63.         e8:a7:8a:6d:d2:cd:37:1f:0a:b8:61:c8:c3:f6:17:83:0f:24:
    64.         0e:06:09:bc:73:09:32:70:f0:2f:9f:b1:7e:b8:ff:36:5c:3c:
    65.         a9:28:69:58:fd:6b:55:2c:1f:8e:28:9c:8d:c9:37:66:9d:28:
    66.         d7:4c:e5:fe:67:45:52:41:68:36:88:26:b1:95:f5:27:43:b3:
    67.         1e:01:23:85:64:14:86:ff:b8:93:9e:06:78:ad:8b:2f:27:d8:
    68.         35:06:49:37:d4:9f:d6:6f:a8:78:1f:b5:cf:96:2b:d7:da:02:
    69.         2c:94:6f:1d:66:5c:e8:a6:a8:c9:e6:65:6a:6a:99:4a:61:a9:
    70.         fe:7d:3e:c8
  2. Create a single truststore: keytool -importcert -file '../ca/rootCa.crt' \
  3. -keystore dse-truststore.jks \
  4. -storepass truststorePass \
  5. -noprompt
    Tip: Even when using a well-known certificate authority, DataStax recommends creating a truststore with the signing CA certificate (or certificate chain following the instructions from your CA).

    The truststore contains a single entry. Verify the truststore using the following command:keytool -list \
  6. -keystore dse-truststore.jks \
  7. -storepass truststorePass

Start here when using a third-party CA or when adding a node to an existing DSE environment with SSL enabled.

  1. For each node in the cluster, create a keystore and key pair, and certificate signing request using FQDN of the node.
    1. Create a directory to store the keystores and change to the directory: mkdir -p dse/keystores
    2. cd dse/keystores
    3. For each node, generate a keystore with key pair: keytool -genkeypair -keyalg RSA \
    4. -alias node_name \
    5. -keystore keystore_name.jks \
    6. -storepass myKeyPass \
    7. -keypass myKeyPass \
    8. -validity 365 \
    9. -keysize 2048 \
    10. -dname "CN=host_name, OU=cluster_name, O=org_name, C=US"
      where the host_name is the FQDN (Fully Qualified Domain Name).Important: Use a DNS resolvable FQDN (Full Qualified Domain Name) for each node, to ensure the information you are using is correct run the following commands on each node: nslookup $(hostname --fqdn) && hostname --fqdn && hostname -i
      Server: 10.200.1.10
    11. Address: 10.200.1.10#53
    12.  
    13. Name: node.example.com
    14. Address: 10.200.182.183
    15.  
    16. node.example.com
    17. 10.200.182.183


    18. Verify each SSL keystore and key pair: keytool -list -keystore keystore_name.jks -storepass myKeyPass

      Results for keystore with single entry with alias node1.Keystore type: JKS
    19. Keystore provider: SUN
    20.  
    21. Your keystore contains 1 entry
    22.  
    23. node1, Jan 23, 2017, PrivateKeyEntry,
    24. Certificate fingerprint (SHA1): 12:B7:45:AA:AD:F0:22:23:3F:13:FC:2C:3D:A4:4F:84:16:96:58:66
    25. Generate a signing request from each keystore: keytool -keystore keystore_name.jks \
    26. -alias node_name \
    27. -certreq -file signing_request.csr \
    28. -keypass myKeyPass \
    29. -storepass myKeyPass \
    30. -dname "CN=host_name, OU=cluster_name, O=org_name, C=US"


    31. The certificate signing request file (signing_request.csr) is created. Repeat for each node, ensuring that the dname information matches the node information.
  2. Sign the certificate signing request of each node:
    1. BYO root CA: Using the root CA created in step 1, sign each nodes certificate:openssl x509 -req -CA '../ca/rootCa.crt' \
    2. -CAkey '../ca/rootCa.key' \
    3. -in node0.csr \
    4. -out node0.crt_signed \
    5. -days 365 \
    6. -CAcreateserial \
    7. -passin pass:myPass

      A signed certificate file is created, verify that was properly signed:openssl verify -CAfile '../ca/rootCa.crt' node0.crt_signed
      node0.crt_signed: OK
    8. Send the certificate signing request to a well-known CA for signing.
  3. For each node in the cluster, import the signed certificates into the keystores:
    1. Import the root certificate into each node's keystore: keytool -keystore node0.keystore.jks \
    2. -alias node_name \
    3. -importcert -file '../ca/rootCa.crt' \
    4. -noprompt  -keypass myKeyPass \
    5. -storepass myKeyPass
      where the following must match the items created in the previous steps:
      • node0.keystore.jks - keystore created in 3.b
      • node_name is the alias used in 3.b, rootCa.
      • rootCa.crt - root certificate

    6. WARNING: An error occurs, keytool error: java.lang.Exception: Failed to establish chain from reply, if the signed certificate for the node is imported before the root certificate.
    7. Import the node's signed certificate into corresponding keystore: keytool -keystore node0.keystore.jks \
    8. -alias node_name \
    9. -importcert -noprompt \
    10. -file node0.crt_signed \
    11. -keypass myKeyPass \
    12. -storepass myKeyPass
      where the alias name must match the alias name used to generate the signing request in step 3.d.
      Confirmation of the installation appears, repeat both steps for each node's keystore:Certificate reply was installed in keystore
  4. Move the truststores and keystores to a computer with access to the DSE nodes and distribute to each node:
    1. Create a directory for the certificates in the DSE configuration directory on each node: mkdir -p dse/conf/certs
    2. Copy the truststore to each node using a generic name: scp dse-truststore.jks \
    3. node0:dse/conf/certs/truststore.jks

      Using the same name and location on all nodes allows the same configuration for SSL in the cassandra.yaml.
    4. Copy the corresponding keystore to each node using a generic name: scp node0.keystore.jks \
    5. node0:dse/conf/certs/keystore.jks
      Important: Be sure to copy the correct keystore to the correct nodes.
Was this article helpful?
0 out of 0 found this helpful
Return to top

Related articles

Didn’t find what you’re looking for?

SUBMIT A TICKET