Add Domain Controller Public Key to CLI Truststore: Difference between revisions
No edit summary |
|||
(17 intermediate revisions by the same user not shown) | |||
Line 13: | Line 13: | ||
=Overview= | =Overview= | ||
The management interface may be protected by configuring it to require all management traffic to go over SSL/TLS. This adds an additional layer of security by preventing management traffic to travel in clear over the network. | The management interface may be protected by configuring it to require all management traffic to go over SSL/TLS. This adds an additional layer of security by preventing management traffic to travel in clear over the network. SSL/TLS enablement on management interfaces is described here: [[WildFly_Management_API_Configuration#Enabling_SSL.2FTSL_for_the_Management_Interfaces|Enabling SSL/TLS for Management Interfaces]]. | ||
However, when the management interface is protected by SSL/TLS, but without additional configuration on CLI client side, the CLI does not recognizes by default the server certificate and challenges the user to manually accept it: | |||
<pre> | |||
NOMBP2:bin ovidiu$ ./jboss-cli.sh --connect --controller=127.0.0.1:9999 | |||
Unable to connect due to unrecognised server certificate | |||
Subject - CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown | |||
Issuer - CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown | |||
Valid From - Mon Mar 20 16:33:27 EDT 2017 | |||
Valid To - Fri Dec 18 15:33:27 EST 2026 | |||
MD5 : 69:25:1b:97:9d:3f:63:80:bd:5d:47:13:97:34:7a:9f | |||
SHA1 : 6c:ac:67:33:6d:9b:fd:22:00:b3:ec:67:76:e9:a3:e4:0c:45:74:9e | |||
Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t | |||
[domain@127.0.0.1:9999 /] | |||
</pre> | |||
The challenge to accept the certificate is issued both in the case of local authentication and username-based authentication. | |||
The client can be configured to automatically accept the certificate, as follows. | |||
=Procedure= | |||
==Export the Server Public Key== | |||
<pre> | |||
keytool -export -keystore <keystore-file> -alias <domain-controller-key-alias> -file domain-controller-key.cer -keypass ... -storepass ... | |||
</pre> | |||
The server (domain controller) key store file name, the domain controller key alias and the password (if not using the vault) are available in $JBOSS_HOME/domain/configuration/host.xml. For more details see [[Enabling_SSL/TSL_for_the_Native_Management_Interface_in_EAP_7_Domain_Mode#Add_a_SSL_Keystore_as_SSL_Server_Identity_under_the_Management_Realm|Enabling SSL/TSL for the Native Management Interface in EAP 7 Domain Mode]]. | |||
==Create the Client's Keystore== | |||
<pre> | |||
keytool -genkey -alias client-key -keyalg RSA -keysize 1024 -keystore client.jks -validity 3650 -keypass client-key123 -storepass client-key123 | |||
</pre> | |||
==Add the Server Public Key to the Client Keystore== | |||
<pre> | |||
keytool -import -v -trustcacerts -alias domain-controller-key -file domain-controller-key.cer -keystore client.jks -keypass client123 -storepass client123 | |||
</pre> | |||
==Add References to the Client Keystore in jboss-cli.sh== | |||
Edit jboss-cli.sh: | |||
<pre> | |||
JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.trustStore=$(dirname $0)/../domain/configuration/client.jks -Djavax.net.ssl.trustStorePassword=client-key123" | |||
</pre> | |||
After the client is configured as such, it should have access to the server's public key, trust it, and stop challenging the user to accept it. |
Latest revision as of 23:21, 20 March 2017
External
- How to avoid manual interaction of accepting certificate while using CLI API? https://access.redhat.com/solutions/701103
Internal
Relevance
EAP 7
Overview
The management interface may be protected by configuring it to require all management traffic to go over SSL/TLS. This adds an additional layer of security by preventing management traffic to travel in clear over the network. SSL/TLS enablement on management interfaces is described here: Enabling SSL/TLS for Management Interfaces.
However, when the management interface is protected by SSL/TLS, but without additional configuration on CLI client side, the CLI does not recognizes by default the server certificate and challenges the user to manually accept it:
NOMBP2:bin ovidiu$ ./jboss-cli.sh --connect --controller=127.0.0.1:9999 Unable to connect due to unrecognised server certificate Subject - CN=Unknown,OU=Unknown,O=Unknown,L=Unknown,ST=Unknown,C=Unknown Issuer - CN=Unknown, OU=Unknown, O=Unknown, L=Unknown, ST=Unknown, C=Unknown Valid From - Mon Mar 20 16:33:27 EDT 2017 Valid To - Fri Dec 18 15:33:27 EST 2026 MD5 : 69:25:1b:97:9d:3f:63:80:bd:5d:47:13:97:34:7a:9f SHA1 : 6c:ac:67:33:6d:9b:fd:22:00:b3:ec:67:76:e9:a3:e4:0c:45:74:9e Accept certificate? [N]o, [T]emporarily, [P]ermenantly : t [domain@127.0.0.1:9999 /]
The challenge to accept the certificate is issued both in the case of local authentication and username-based authentication.
The client can be configured to automatically accept the certificate, as follows.
Procedure
Export the Server Public Key
keytool -export -keystore <keystore-file> -alias <domain-controller-key-alias> -file domain-controller-key.cer -keypass ... -storepass ...
The server (domain controller) key store file name, the domain controller key alias and the password (if not using the vault) are available in $JBOSS_HOME/domain/configuration/host.xml. For more details see Enabling SSL/TSL for the Native Management Interface in EAP 7 Domain Mode.
Create the Client's Keystore
keytool -genkey -alias client-key -keyalg RSA -keysize 1024 -keystore client.jks -validity 3650 -keypass client-key123 -storepass client-key123
Add the Server Public Key to the Client Keystore
keytool -import -v -trustcacerts -alias domain-controller-key -file domain-controller-key.cer -keystore client.jks -keypass client123 -storepass client123
Add References to the Client Keystore in jboss-cli.sh
Edit jboss-cli.sh:
JAVA_OPTS="${JAVA_OPTS} -Djavax.net.ssl.trustStore=$(dirname $0)/../domain/configuration/client.jks -Djavax.net.ssl.trustStorePassword=client-key123"
After the client is configured as such, it should have access to the server's public key, trust it, and stop challenging the user to accept it.