Typically contains 1 private key for the host system.Ĭontains the certificate for the host's private key.Ĭontains root certificates for well-known public certificate authorities. Used by the client side of a TLS/SSL client-server connection. Used by the server side of a TLS/SSL client-server connection. This table summarizes the general differences between keystoreĪnd the truststore in Cloudera Manager Server clusters. For Cloudera Manager Server clusters, each host should have its own keystore, while several hosts can share the same truststore. Keytool-Key and Certificate Management ToolĪlthough the keystore and truststore in some environments may comprise the same file, as configured for Cloudera Manager Server and CDH clusters, the keystore and truststore are distinctįiles.Note: For detailed information about the Java keystore and truststore, see Oracle documentation: The private keys are maintained in the keystore. See Generate TLS Certificates for details. After jssecacerts has been created, new public and private root CAs are added to it for use by the cluster. Important: For use with Cloudera clusters, the alternative trust store- jssecacerts-must start as aĬopy of cacerts because cacerts contains all available default certificates needed to establish the chain This alternative truststore is loaded by Hadoop daemons at startup. Certificates canīe added to this truststore when needed for additional roles or services. The alternative truststore is created by copying cacerts to that filename ( jssecacerts). Rather than using the default truststore, Cloudera recommends using the alternative truststore, jssecacerts.
The standard Oracle Java JDK distribution includes a default truststore ( cacerts) that contains root certificates for many The certificatesĪssure the client or server process that the issuing authority for the certificate is part of a legitimate chain of trust. All clients in a Cloudera Manager cluster configured for TLS/SSL need access to the truststore to validate certificates presented during TLS/SSL session negotiation.
0 kommentar(er)
