knox-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kris...@apache.org
Subject svn commit: r1854743 - in /knox: site/books/knox-1-3-0/user-guide.html site/index.html site/issue-management.html site/licenses.html site/mailing-lists.html site/project-info.html site/team.html trunk/books/1.3.0/config.md
Date Sun, 03 Mar 2019 21:01:59 GMT
Author: krisden
Date: Sun Mar  3 21:01:59 2019
New Revision: 1854743

URL: http://svn.apache.org/viewvc?rev=1854743&view=rev
Log:
KNOX-1796 - Update documentation with configurable TLS keystore information (Robert Levas via Kevin Risden)

Modified:
    knox/site/books/knox-1-3-0/user-guide.html
    knox/site/index.html
    knox/site/issue-management.html
    knox/site/licenses.html
    knox/site/mailing-lists.html
    knox/site/project-info.html
    knox/site/team.html
    knox/trunk/books/1.3.0/config.md

Modified: knox/site/books/knox-1-3-0/user-guide.html
URL: http://svn.apache.org/viewvc/knox/site/books/knox-1-3-0/user-guide.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/books/knox-1-3-0/user-guide.html (original)
+++ knox/site/books/knox-1-3-0/user-guide.html Sun Mar  3 21:01:59 2019
@@ -771,11 +771,6 @@ https://{gateway-host}:{gateway-port}/{g
       <td><code>JKS</code></td>
     </tr>
     <tr>
-      <td><code>gateway.keystore.type</code></td>
-      <td>Indicates the type of keystore for the identity store</td>
-      <td><code>JKS</code></td>
-    </tr>
-    <tr>
       <td><code>gateway.jdk.tls.ephemeralDHKeySize</code></td>
       <td><code>jdk.tls.ephemeralDHKeySize</code>, is defined to customize the ephemeral DH key sizes. The minimum acceptable DH key size is 1024 bits, except for exportable cipher suites or legacy mode (<code>jdk.tls.ephemeralDHKeySize=legacy</code>)</td>
       <td><code>2048</code></td>
@@ -826,16 +821,56 @@ https://{gateway-host}:{gateway-port}/{g
       <td><code>false</code></td>
     </tr>
     <tr>
+      <td><code>gateway.tls.keystore.password.alias</code></td>
+      <td>OPTIONAL Alias for the password to the keystore file holding the Gateway&rsquo;s TLS certificate and keypair. NOTE: An alias with the provided name should be created using <code>knoxcli.sh create-alias</code> inorder to provide the password; else the master secret will be used.</td>
+      <td><code>gateway-identity-keystore-password</code></td>
+    </tr>
+    <tr>
+      <td><code>gateway.tls.keystore.path</code></td>
+      <td>OPTIONAL The path to the keystore file where the Gateway&rsquo;s TLS certificate and keypair are stored. If not set, the default keystore file will be used - data/security/keystores/gateway.jks.</td>
+      <td>null</td>
+    </tr>
+    <tr>
+      <td><code>gateway.tls.keystore.type</code></td>
+      <td>OPTIONAL The type of the keystore file where the Gateway&rsquo;s TLS certificate and keypair are stored. See <code>gateway.tls.keystore.path</code>.</td>
+      <td><code>JKS</code></td>
+    </tr>
+    <tr>
+      <td><code>gateway.tls.key.alias</code></td>
+      <td>OPTIONAL The alias for the Gateway&rsquo;s TLS certificate and keypair within the default keystore or the keystore specified via <code>gateway.tls.keystore.path</code>.</td>
+      <td><code>gateway-identity</code></td>
+    </tr>
+    <tr>
+      <td><code>gateway.tls.key.passphrase.alias</code></td>
+      <td>OPTIONAL The alias for passphrase for the Gateway&rsquo;s TLS private key stored within the default keystore or the keystore specified via <code>gateway.tls.keystore.path</code>. NOTE: An alias with the provided name should be created using <code>knoxcli.sh create-alias</code> inorder to provide the password; else the keystore password or the master secret will be used. See <code>gateway.tls.keystore.password.alias</code></td>
+      <td><code>gateway-identity-passphrase</code></td>
+    </tr>
+    <tr>
       <td><code>gateway.signing.keystore.name</code></td>
       <td>OPTIONAL Filename of keystore file that contains the signing keypair. NOTE: An alias needs to be created using <code>knoxcli.sh create-alias</code> for the alias name <code>signing.key.passphrase</code> in order to provide the passphrase to access the keystore.</td>
       <td>null</td>
     </tr>
     <tr>
+      <td><code>gateway.signing.keystore.password.alias</code></td>
+      <td>OPTIONAL Alias for the password to the keystore file holding the signing keypair. NOTE: An alias with the provided name should be created using <code>knoxcli.sh create-alias</code> inorder to provide the password; else the master secret will be used.</td>
+      <td><code>signing.keystore.password</code></td>
+    </tr>
+    <tr>
+      <td><code>gateway.signing.keystore.type</code></td>
+      <td>OPTIONAL The type of the keystore file where the signing keypair is stored. See <code>gateway.signing.keystore.name</code>.</td>
+      <td><code>JKS</code></td>
+    </tr>
+    <tr>
       <td><code>gateway.signing.key.alias</code></td>
       <td>OPTIONAL alias for the signing keypair within the keystore specified via <code>gateway.signing.keystore.name</code></td>
       <td>null</td>
     </tr>
     <tr>
+      <td><code>gateway.signing.key.passphrase.alias</code></td>
+      <td>OPTIONAL The alias for passphrase for signing private key stored within the default keystore or the keystore specified via <code>gateway.signing.keystore.name</code>. NOTE: An alias with the provided name should be created using <code>knoxcli.sh create-alias</code> inorder to provide the password; else the keystore password or the master secret will be used. See <code>gateway.signing.keystore.password.alias</code></td>
+      <td><code>signing.key.passphrase</code></td>
+    </tr>
+    <tr>
       <td><code>ssl.enabled</code></td>
       <td>Indicates whether SSL is enabled for the Gateway</td>
       <td><code>true</code></td>
@@ -1463,7 +1498,7 @@ trustworthiness.
 <h4><a id="Java+VM+Options">Java VM Options</a> <a href="#Java+VM+Options"><img src="markbook-section-link.png"/></a></h4>
 <p>TODO - Java VM options doc.</p>
 <h4><a id="Persisting+the+Master+Secret">Persisting the Master Secret</a> <a href="#Persisting+the+Master+Secret"><img src="markbook-section-link.png"/></a></h4>
-<p>The master secret is required to start the server. This secret is used to access secured artifacts by the gateway instance. Keystore, trust stores and credential stores are all protected with the master secret.</p>
+<p>The master secret is required to start the server. This secret is used to access secured artifacts by the gateway instance. By default, the keystores, trust stores, and credential stores are all protected with the master secret. However, if a custom keystore is set, it and the contained keys may have different passwords. </p>
 <p>You may persist the master secret by supplying the <em>-persist-master</em> switch at startup. This will result in a warning indicating that persisting the secret is less secure than providing it at startup. We do make some provisions in order to protect the persisted password.</p>
 <p>It is encrypted with AES 128 bit encryption and where possible the file permissions are set to only be accessible by the user that the gateway is running as.</p>
 <p>After persisting the secret, ensure that the file at <code>data/security/master</code> has the appropriate permissions set for your environment. This is probably the most important layer of defense for master secret. Do not assume that the encryption is sufficient protection.</p>
@@ -1472,18 +1507,24 @@ trustworthiness.
 <h4><a id="Management+of+Security+Artifacts">Management of Security Artifacts</a> <a href="#Management+of+Security+Artifacts"><img src="markbook-section-link.png"/></a></h4>
 <p>There are a number of artifacts that are used by the gateway in ensuring the security of wire level communications, access to protected resources and the encryption of sensitive data. These artifacts can be managed from outside of the gateway instances or generated and populated by the gateway instance itself.</p>
 <p>The following is a description of how this is coordinated with both standalone (development, demo, etc.) gateway instances and instances as part of a cluster of gateways in mind.</p>
-<p>Upon start of the gateway server we:</p>
+<p>Upon start of the gateway server:</p>
 <ol>
-  <li>Look for an identity store at <code>data/security/keystores/gateway.jks</code>.  The identity store contains the certificate and private key used to represent the identity of the server for SSL connections and signature creation.
+  <li>Look for a credential store at <code>data/security/keystores/__gateway-credentials.jceks</code>.  This credential store is used to store secrets/passwords that are used by the gateway.  For instance, this is where the passphrase for accessing the gateway&rsquo;s TLS certificate is kept.
+    <ul>
+      <li>If the credential store is not found, then one is created and encrypted with the provided master secret.</li>
+      <li>If the credential store is found, then it is loaded using the provided master secret.</li>
+    </ul>
+  </li>
+  <li>Look for an identity keystore at the configured location. If a configured location was not set, the  default location, <code>data/security/keystores/gateway.jks</code>, will be used. The identity keystore contains  the certificate and private key used to represent the identity of the server for TLS/SSL connections.
     <ul>
-      <li>If there is no identity store we create one and generate a self-signed certificate for use in standalone/demo mode.  The certificate is stored with an alias of gateway-identity.</li>
-      <li>If there is an identity store found than we ensure that it can be loaded using the provided master secret and that there is an alias called gateway-identity.</li>
+      <li>If the identity keystore was not found, one is created in the configured or default location.<br/> Then a self-signed certificate for use in standalone/demo mode is generated and stored with the  configured identity alias or the default alias of &ldquo;gateway-identity&rdquo;.</li>
+      <li>If the identity keystore is found, then it is loaded using either the password found in the  credential store under the configured alias name or the provided master secret. It is tested  to ensure that a certificate and private key are found using the configured alias name or  the default alias of &ldquo;gateway-identity&rdquo;.</li>
     </ul>
   </li>
-  <li>Look for a credential store at <code>data/security/keystores/__gateway-credentials.jceks</code>.  This credential store is used to store secrets/passwords that are used by the gateway.  For instance, this is where the passphrase for accessing the gateway-identity certificate is kept.
+  <li>Look for a signing keystore at the configured location or the default location of <code>data/security/keystores/gateway.jks</code>.<br/> The signing keystore contains the public and private key used for signature creation.
     <ul>
-      <li>If there is no credential store found then we create one and populate it with a generated passphrase for the alias <code>gateway-identity-passphrase</code>.  This is coordinated with the population of the self-signed cert into the identity-store.</li>
-      <li>If a credential store is found then we ensure that it can be loaded using the provided master secret and that the expected aliases have been populated with secrets.</li>
+      <li>If the signing keystore was not found, the server will fail to start.</li>
+      <li>If the signing keystore is found, then it is loaded using either the password found in the  credential store under the configured alias name or the provided master secret. It is tested  to ensure that a public and private key are found using the configured alias name or  the default alias of &ldquo;gateway-identity&rdquo;.</li>
     </ul>
   </li>
 </ol>
@@ -1504,33 +1545,46 @@ trustworthiness.
 </ol>
 <p>See the Knox CLI section for descriptions of the command line utilities related to the security artifact management.</p>
 <h4><a id="Keystores">Keystores</a> <a href="#Keystores"><img src="markbook-section-link.png"/></a></h4>
-<p>In order to provide your own certificate for use by the gateway, you will need to either import an existing key pair into a Java keystore or generate a self-signed cert using the Java keytool.</p>
+<p>In order to provide your own certificate for use by the Gateway, you may either</p>
+<ul>
+  <li>provide your own keystore</li>
+  <li>import an existing key pair into the default Gateway keystore</li>
+  <li>generate a self-signed cert using the Java keytool</li>
+</ul>
+<h5><a id="Providing+your+own+keystore">Providing your own keystore</a> <a href="#Providing+your+own+keystore"><img src="markbook-section-link.png"/></a></h5>
+<p>A keystore in one of the following formats may be specified: </p>
+<ul>
+  <li>JKS: Java KeyStore file</li>
+  <li>JCEKS: Java Cryptology Extension KeyStore file</li>
+  <li>PKCS12: PKCS #12 file</li>
+</ul>
+<p>See <code>gateway.tls.keystore.password.alias</code>, <code>gateway.tls.keystore.path</code>, <code>gateway.tls.keystore.type</code>, <code>gateway.tls.key.alias</code>, and <code>gateway.tls.key.passphrase.alias</code> under <em>Gateway Server Configuration</em> for information on configuring the Gateway to use this keystore.</p>
 <h5><a id="Importing+a+key+pair+into+a+Java+keystore">Importing a key pair into a Java keystore</a> <a href="#Importing+a+key+pair+into+a+Java+keystore"><img src="markbook-section-link.png"/></a></h5>
 <p>One way to accomplish this is to start with a PKCS12 store for your key pair and then convert it to a Java keystore or JKS.</p>
 <p>The following example uses OpenSSL to create a PKCS12 encoded store from your provided certificate and private key that are in PEM format.</p>
 <pre><code>openssl pkcs12 -export -in cert.pem -inkey key.pem &gt; server.p12
 </code></pre>
-<p>The next example converts the PKCS12 store into a Java keystore (JKS). It should prompt you for the keystore and key passwords for the destination keystore. You must use the master-secret for the keystore password and keep track of the password that you use for the key passphrase.</p>
+<p>The next example converts the PKCS12 store into a Java keystore (JKS). It should prompt you for the keystore and key passwords for the destination keystore. You must use either the master-secret for the keystore password and key passphrase or choose you own. If you choose your own passwords, you must use the Knox CLI utility to provide them to the Gateway. </p>
 <pre><code>keytool -importkeystore -srckeystore server.p12 -destkeystore gateway.jks -srcstoretype pkcs12
 </code></pre>
 <p>While using this approach a couple of important things to be aware of:</p>
 <ol>
   <li>
-    <p>the alias MUST be &ldquo;gateway-identity&rdquo;. You may need to change it using keytool after the import of the PKCS12 store. You can use keytool to do this - for example:</p>
+    <p>The alias MUST be properly set. If it is not the default value (&ldquo;gateway-identity&rdquo;), it must be  set in the configuration using <code>gateway.tls.key.alias</code>. You may need to change it using keytool  after the import of the PKCS12 store. You can use keytool to do this - for example:</p>
     <pre><code>keytool -changealias -alias &quot;1&quot; -destalias &quot;gateway-identity&quot; -keystore gateway.jks -storepass {knoxpw}
 </code></pre>
   </li>
   <li>
-  <p>the name of the expected identity keystore for the gateway MUST be <code>gateway.jks</code></p></li>
-  <li>the passwords for the keystore and the imported key may both be set to the master secret for the gateway install. You can change the key passphrase after import using keytool as well. You may need to do this in order to provision the password in the credential store as described later in this section. For example:
+  <p>The path to the identity keystore for the gateway MUST be the default path  (<code>{GATEWAY_HOME}/data/security/keystores/gateway.jks</code>) or MUST be specified in the configuration  using <code>gateway.tls.keystore.path</code> and <code>gateway.tls.keystore.type</code> </p></li>
+  <li>The passwords for the keystore and the imported key may both be set to the master secret for the  gateway install. If a custom password is used, the passwords must be imported into the credential  store using the Knox CLI <code>create-alias</code> command. The aliases for the passwords must then be set  in the configuration using <code>gateway.tls.keystore.password.alias</code> and <code>gateway.tls.key.passphrase.alias</code>.<br/> If both the keystore password and the key passphrase are the same, only <code>gateway.tls.keystore.password.alias</code>  needs to be set. You can change the key passphrase after import using keytool. You may need to  do this in order to provision the password in the credential store as described later in this  section. For example:
     <pre><code>keytool -keypasswd -alias gateway-identity -keystore gateway.jks
 </code></pre>
   </li>
 </ol>
-<p>NOTE: The password for the keystore as well as that of the imported key may be the master secret for the gateway instance or you may set the gateway-identity-passphrase alias using the Knox CLI to the actual key passphrase. See the Knox CLI section for details.</p>
-<p>The following will allow you to provision the passphrase for the private key that you set during keystore creation above - it will prompt you for the actual passphrase.</p>
-<pre><code>bin/knoxcli.sh create-alias gateway-identity-passphrase
+<p>The following will allow you to provision the password for the keystore or the passphrase for the private key that was set during keystore creation above - it will prompt you for the actual password/passphrase.</p>
+<pre><code>bin/knoxcli.sh create-alias &lt;alias name&gt;
 </code></pre>
+<p>The default alias for the keystore password is <code>gateway-identity-keystore-password</code>, to use a different alias, set <code>gateway.tls.keystore.password.alias</code> in the configuration. The default alias for the key passphrase is <code>gateway-identity-keystore-password</code>, to use a different alias, set <code>gateway.tls.key.passphrase.alias</code> in the configuration.</p>
 <h5><a id="Generating+a+self-signed+cert+for+use+in+testing+or+development+environments">Generating a self-signed cert for use in testing or development environments</a> <a href="#Generating+a+self-signed+cert+for+use+in+testing+or+development+environments"><img src="markbook-section-link.png"/></a></h5>
 <pre><code>keytool -genkey -keyalg RSA -alias gateway-identity -keystore gateway.jks \
     -storepass {master-secret} -validity 360 -keysize 2048
@@ -1541,8 +1595,8 @@ trustworthiness.
 <p>See the Knox CLI section for descriptions of the command line utilities related to the management of the keystores.</p>
 <h5><a id="Using+a+CA+Signed+Key+Pair">Using a CA Signed Key Pair</a> <a href="#Using+a+CA+Signed+Key+Pair"><img src="markbook-section-link.png"/></a></h5>
 <p>For certain deployments a certificate key pair that is signed by a trusted certificate authority is required. There are a number of different ways in which these certificates are acquired and can be converted and imported into the Apache Knox keystore.</p>
-<p>The following steps have been used to do this and are provided here for guidance in your installation. You may have to adjust according to your environment.</p>
-<p>General steps:</p>
+<h6><a id="Option+#1">Option #1</a> <a href="#Option+#1"><img src="markbook-section-link.png"/></a></h6>
+<p>One way to do this is to install the certificate and keys in the default identity keystore and the master secret. The following steps have been used to do this and are provided here for guidance in your installation. You may have to adjust according to your environment.</p>
 <ol>
   <li>
     <p>Stop Knox gateway and back up all files in <code>{GATEWAY_HOME}/data/security/keystores</code></p>
@@ -1582,19 +1636,57 @@ keytool -keystore gateway.jks -storepass
   </li>
   <li>
     <p>Restart Knox gateway. Check <code>gateway.log</code> to check whether the gateway started properly and clusters are deployed. You can check the timestamp on cluster deployment files</p>
-    <pre><code>ls -alrt {GATEWAY_HOME}/data/deployment
+    <pre><code>gateway.sh start
+ls -alrt {GATEWAY_HOME}/data/deployment
+</code></pre>
+  </li>
+  <li>
+    <p>Verify that clients can use the CA authority cert to access Knox (which is the goal of using public signed cert) using curl or a web browser which has the CA certificate installed</p>
+    <pre><code>curl --cacert PATH_TO_CA_CERT -u tom:tom-password -X GET https://localhost:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
+</code></pre>
+  </li>
+</ol>
+<h6><a id="Option+#2">Option #2</a> <a href="#Option+#2"><img src="markbook-section-link.png"/></a></h6>
+<p>Another way to do this is to place the CA signed keypair in it&rsquo;s own keystore. The creation of this keystore is out of scope for this document. However, once created, the following steps can be use to configure the Knox Gateway to use it. </p>
+<ol>
+  <li>
+  <p>Move the new keystore into a location that the Knox Gateway can access.</p></li>
+  <li>
+    <p>Edit the gateway-site.xml file to set the configurations </p>
+    <ul>
+      <li><code>gateway.tls.keystore.password.alias</code> - Alias of the password for the keystore</li>
+      <li><code>gateway.tls.keystore.path</code> - Path to the keystore file</li>
+      <li><code>gateway.tls.keystore.type</code> - Type of keystore file (JKS, JCEKS, PKCS12)</li>
+      <li><code>gateway.tls.key.alias</code> - Alias for the certificate and key</li>
+      <li><code>gateway.tls.key.passphrase.alias</code> - Alias of the passphrase for the key  (needed if the passphrase is different than the keystore password)</li>
+    </ul>
+  </li>
+  <li>
+    <p>Provision the relevant passwords using the Knox CLI</p>
+    <pre><code>knoxcli.sh create-alias &lt;alias&gt; --value &lt;password/passphrase&gt;
+</code></pre>
+  </li>
+  <li>
+    <p>Stop Knox gateway</p>
+    <pre><code>gateway.sh stop
+</code></pre>
+  </li>
+  <li>
+    <p>Restart Knox gateway. Check <code>gateway.log</code> to check whether the gateway started properly and  clusters are deployed. You can check the timestamp on cluster deployment files</p>
+    <pre><code>gateway.sh start
+ls -alrt {GATEWAY_HOME}/data/deployment
 </code></pre>
   </li>
   <li>
-    <p>Verify that clients can use the CA authority cert to access Knox (which is the goal of using public signed cert) using curl or a web browsers which has the CA certificate installed</p>
+    <p>Verify that clients can use the CA authority cert to access Knox (which is the goal of using  public signed cert) using curl or a web browsers which has the CA certificate installed</p>
     <pre><code>curl --cacert supwin12ad.cer -u hdptester:hadoop -X GET &#39;https://$fqdn_knox:8443/gateway/$topologyname/webhdfs/v1/tmp?op=LISTSTATUS&#39;
 </code></pre>
   </li>
 </ol>
 <h5><a id="Credential+Store">Credential Store</a> <a href="#Credential+Store"><img src="markbook-section-link.png"/></a></h5>
-<p>Whenever you provide your own keystore with either a self-signed cert or an issued certificate signed by a trusted authority, you will need to set an alias for the <code>gateway-identity-passphrase</code> or create an empty credential store. This is necessary for the current release in order for the system to determine the correct password for the keystore and the key.</p>
+<p>Whenever you provide your own keystore with either a self-signed cert or an issued certificate signed by a trusted authority, you will need to set an alias for the keystore password and key passphrase. This is necessary for the current release in order for the system to determine the correct passwords to use for the keystore and the key.</p>
 <p>The credential stores in Knox use the JCEKS keystore type as it allows for the storage of general secrets in addition to certificates.</p>
-<p>Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. These aliases are managed within credential stores which are created by the CLI as needed. The simplest approach is to create the <code>gateway-identity-passphrase</code> alias with the Knox CLI. This will create the credential store if it doesn&rsquo;t already exist and add the key passphrase.</p>
+<p>Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. These aliases are managed within credential stores which are created by the CLI as needed. The simplest approach is to create the relevant aliases with the Knox CLI. This will create the credential store if it does not already exist and add the password or passphrase.</p>
 <p>See the Knox CLI section for descriptions of the command line utilities related to the management of the credential stores.</p>
 <h5><a id="Provisioning+of+Keystores">Provisioning of Keystores</a> <a href="#Provisioning+of+Keystores"><img src="markbook-section-link.png"/></a></h5>
 <p>Once you have created these keystores you must move them into place for the gateway to discover them and use them to represent its identity for SSL connections. This is done by copying the keystores to the <code>{GATEWAY_HOME}/data/security/keystores</code> directory for your gateway install.</p>

Modified: knox/site/index.html
URL: http://svn.apache.org/viewvc/knox/site/index.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/index.html (original)
+++ knox/site/index.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from src/site/markdown/index.md at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from src/site/markdown/index.md at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Announcing Apache Knox 1.2.0!</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/site/issue-management.html
URL: http://svn.apache.org/viewvc/knox/site/issue-management.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/issue-management.html (original)
+++ knox/site/issue-management.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:issue-management at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:issue-management at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Issue Management</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/site/licenses.html
URL: http://svn.apache.org/viewvc/knox/site/licenses.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/licenses.html (original)
+++ knox/site/licenses.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:licenses at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:licenses at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Licenses</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/site/mailing-lists.html
URL: http://svn.apache.org/viewvc/knox/site/mailing-lists.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/mailing-lists.html (original)
+++ knox/site/mailing-lists.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:mailing-lists at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:mailing-lists at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Mailing Lists</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/site/project-info.html
URL: http://svn.apache.org/viewvc/knox/site/project-info.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/project-info.html (original)
+++ knox/site/project-info.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-site-plugin:3.7.1:CategorySummaryDocumentRenderer at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Information</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/site/team.html
URL: http://svn.apache.org/viewvc/knox/site/team.html?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/site/team.html (original)
+++ knox/site/team.html Sun Mar  3 21:01:59 2019
@@ -1,13 +1,13 @@
 <!DOCTYPE html>
 <!--
- | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at 2019-03-01
+ | Generated by Apache Maven Doxia Site Renderer 1.8.1 from org.apache.maven.plugins:maven-project-info-reports-plugin:3.0.0:team at 2019-03-03
  | Rendered using Apache Maven Fluido Skin 1.7
 -->
 <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="Date-Revision-yyyymmdd" content="20190301" />
+    <meta name="Date-Revision-yyyymmdd" content="20190303" />
     <meta http-equiv="Content-Language" content="en" />
     <title>Knox Gateway &#x2013; Project Team</title>
     <link rel="stylesheet" href="./css/apache-maven-fluido-1.7.min.css" />
@@ -40,7 +40,7 @@
 
       <div id="breadcrumbs">
         <ul class="breadcrumb">
-        <li id="publishDate">Last Published: 2019-03-01</li>
+        <li id="publishDate">Last Published: 2019-03-03</li>
         </ul>
       </div>
       <div class="row-fluid">

Modified: knox/trunk/books/1.3.0/config.md
URL: http://svn.apache.org/viewvc/knox/trunk/books/1.3.0/config.md?rev=1854743&r1=1854742&r2=1854743&view=diff
==============================================================================
--- knox/trunk/books/1.3.0/config.md (original)
+++ knox/trunk/books/1.3.0/config.md Sun Mar  3 21:01:59 2019
@@ -124,7 +124,6 @@ Property    | Description | Default
 `gateway.client.auth.needed`|Indicates whether clients are required to establish a trust relationship with client certificates|`false`  
 `gateway.truststore.path`|Location of the truststore for client certificates to be trusted|`gateway.jks` 
 `gateway.truststore.type`|Indicates the type of truststore|`JKS`
-`gateway.keystore.type`|Indicates the type of keystore for the identity store|`JKS`
 `gateway.jdk.tls.ephemeralDHKeySize`|`jdk.tls.ephemeralDHKeySize`, is defined to customize the ephemeral DH key sizes. The minimum acceptable DH key size is 1024 bits, except for exportable cipher suites or legacy mode (`jdk.tls.ephemeralDHKeySize=legacy`)|`2048`
 `gateway.threadpool.max`|The maximum concurrent requests the server will process. The default is 254. Connections beyond this will be queued.|`254`
 `gateway.httpclient.maxConnections`|The maximum number of connections that a single HttpClient will maintain to a single host:port.|`32`
@@ -135,8 +134,16 @@ Property    | Description | Default
 `gateway.httpserver.responseBuffer`|The size of the HTTP server response buffer in bytes|`32768`
 `gateway.httpserver.responseHeaderBuffer`|The size of the HTTP server response header buffer in bytes|`8192`
 `gateway.websocket.feature.enabled`|Enable/Disable WebSocket feature|`false`
+`gateway.tls.keystore.password.alias`|OPTIONAL Alias for the password to the keystore file holding the Gateway's TLS certificate and keypair. NOTE: An alias with the provided name should be created using `knoxcli.sh create-alias` inorder to provide the password; else the master secret will be used.|`gateway-identity-keystore-password`
+`gateway.tls.keystore.path`|OPTIONAL The path to the keystore file where the Gateway's TLS certificate and keypair are stored. If not set, the default keystore file will be used - data/security/keystores/gateway.jks.|null
+`gateway.tls.keystore.type`|OPTIONAL The type of the keystore file where the Gateway's TLS certificate and keypair are stored. See `gateway.tls.keystore.path`.|`JKS`
+`gateway.tls.key.alias`|OPTIONAL The alias for the Gateway's TLS certificate and keypair within the default keystore or the keystore specified via `gateway.tls.keystore.path`.|`gateway-identity`
+`gateway.tls.key.passphrase.alias`|OPTIONAL The alias for passphrase for the Gateway's TLS private key stored within the default keystore or the keystore specified via `gateway.tls.keystore.path`.  NOTE: An alias with the provided name should be created using `knoxcli.sh create-alias` inorder to provide the password; else the keystore password or the master secret will be used. See `gateway.tls.keystore.password.alias`|`gateway-identity-passphrase`
 `gateway.signing.keystore.name`|OPTIONAL Filename of keystore file that contains the signing keypair. NOTE: An alias needs to be created using `knoxcli.sh create-alias` for the alias name `signing.key.passphrase` in order to provide the passphrase to access the keystore.|null
+`gateway.signing.keystore.password.alias`|OPTIONAL Alias for the password to the keystore file holding the signing keypair. NOTE: An alias with the provided name should be created using `knoxcli.sh create-alias` inorder to provide the password; else the master secret will be used.|`signing.keystore.password`
+`gateway.signing.keystore.type`|OPTIONAL The type of the keystore file where the signing keypair is stored. See `gateway.signing.keystore.name`.|`JKS`
 `gateway.signing.key.alias`|OPTIONAL alias for the signing keypair within the keystore specified via `gateway.signing.keystore.name`|null
+`gateway.signing.key.passphrase.alias`|OPTIONAL The alias for passphrase for signing private key stored within the default keystore or the keystore specified via `gateway.signing.keystore.name`.  NOTE: An alias with the provided name should be created using `knoxcli.sh create-alias` inorder to provide the password; else the keystore password or the master secret will be used. See `gateway.signing.keystore.password.alias`|`signing.key.passphrase`
 `ssl.enabled`|Indicates whether SSL is enabled for the Gateway|`true`
 `ssl.include.ciphers`|A comma or pipe separated list of ciphers to accept for SSL. See the [JSSE Provider docs](http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider) for possible ciphers. These can also contain regular expressions as shown in the [Jetty documentation](http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html).|all
 `ssl.exclude.ciphers`|A comma or pipe separated list of ciphers to reject for SSL. See the [JSSE Provider docs](http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider) for possible ciphers. These can also contain regular expressions as shown in the [Jetty documentation](http://www.eclipse.org/jetty/documentation/current/configuring-ssl.html).|none
@@ -812,7 +819,8 @@ TODO - Java VM options doc.
 
 The master secret is required to start the server.
 This secret is used to access secured artifacts by the gateway instance.
-Keystore, trust stores and credential stores are all protected with the master secret.
+By default, the keystores, trust stores, and credential stores are all protected with the master secret.
+However, if a custom keystore is set, it and the contained keys may have different passwords. 
 
 You may persist the master secret by supplying the *\-persist-master* switch at startup.
 This will result in a warning indicating that persisting the secret is less secure than providing it at startup.
@@ -835,19 +843,30 @@ These artifacts can be managed from outs
 
 The following is a description of how this is coordinated with both standalone (development, demo, etc.) gateway instances and instances as part of a cluster of gateways in mind.
 
-Upon start of the gateway server we:
+Upon start of the gateway server:
 
-1. Look for an identity store at `data/security/keystores/gateway.jks`.
-   The identity store contains the certificate and private key used to represent the identity of the server for SSL connections and signature creation.
-    * If there is no identity store we create one and generate a self-signed certificate for use in standalone/demo mode.
-      The certificate is stored with an alias of gateway-identity.
-    * If there is an identity store found than we ensure that it can be loaded using the provided master secret and that there is an alias called gateway-identity.
-2. Look for a credential store at `data/security/keystores/__gateway-credentials.jceks`.
+1. Look for a credential store at `data/security/keystores/__gateway-credentials.jceks`.
    This credential store is used to store secrets/passwords that are used by the gateway.
-   For instance, this is where the passphrase for accessing the gateway-identity certificate is kept.
-    * If there is no credential store found then we create one and populate it with a generated passphrase for the alias `gateway-identity-passphrase`.
-      This is coordinated with the population of the self-signed cert into the identity-store.
-    * If a credential store is found then we ensure that it can be loaded using the provided master secret and that the expected aliases have been populated with secrets.
+   For instance, this is where the passphrase for accessing the gateway's TLS certificate is kept.
+    * If the credential store is not found, then one is created and encrypted with the provided master secret.
+    * If the credential store is found, then it is loaded using the provided master secret.
+2. Look for an identity keystore at the configured location. If a configured location was not set, the 
+   default location, `data/security/keystores/gateway.jks`, will be used. The identity keystore contains 
+   the certificate and private key used to represent the identity of the server for TLS/SSL connections.   
+    * If the identity keystore was not found, one is created in the configured or default location.  
+      Then a self-signed certificate for use in standalone/demo mode is generated and stored with the 
+      configured identity alias or the default alias of "gateway-identity".
+    * If the identity keystore is found, then it is loaded using either the password found in the 
+      credential store under the configured alias name or the provided master secret. It is tested 
+      to ensure that a certificate and private key are found using the configured alias name or
+      the default alias of "gateway-identity".
+3. Look for a signing keystore at the configured location or the default location of `data/security/keystores/gateway.jks`.  
+   The signing keystore contains the public and private key used for signature creation.
+    * If the signing keystore was not found, the server will fail to start.  
+    * If the signing keystore is found, then it is loaded using either the password found in the 
+      credential store under the configured alias name or the provided master secret. It is tested 
+      to ensure that a public and private key are found using the configured alias name or
+      the default alias of "gateway-identity".
 
 Upon deployment of a Hadoop cluster topology within the gateway we:
 
@@ -866,7 +885,22 @@ By leveraging the algorithm described ab
 See the Knox CLI section for descriptions of the command line utilities related to the security artifact management.
 
 #### Keystores ####
-In order to provide your own certificate for use by the gateway, you will need to either import an existing key pair into a Java keystore or generate a self-signed cert using the Java keytool.
+In order to provide your own certificate for use by the Gateway, you may either
+
+- provide your own keystore 
+- import an existing key pair into the default Gateway keystore 
+- generate a self-signed cert using the Java keytool
+
+##### Providing your own keystore #####
+A keystore in one of the following formats may be specified: 
+
+- JKS: Java KeyStore file
+- JCEKS: Java Cryptology Extension KeyStore file
+- PKCS12: PKCS #12 file
+
+See `gateway.tls.keystore.password.alias`, `gateway.tls.keystore.path`, `gateway.tls.keystore.type`, 
+`gateway.tls.key.alias`, and `gateway.tls.key.passphrase.alias` under *Gateway Server Configuration*
+for information on configuring the Gateway to use this keystore.
 
 ##### Importing a key pair into a Java keystore #####
 One way to accomplish this is to start with a PKCS12 store for your key pair and then convert it to a Java keystore or JKS.
@@ -875,26 +909,45 @@ The following example uses OpenSSL to cr
 
     openssl pkcs12 -export -in cert.pem -inkey key.pem > server.p12
 
-The next example converts the PKCS12 store into a Java keystore (JKS). It should prompt you for the keystore and key passwords for the destination keystore. You must use the master-secret for the keystore password and keep track of the password that you use for the key passphrase.
+The next example converts the PKCS12 store into a Java keystore (JKS). It should prompt you for the 
+keystore and key passwords for the destination keystore. You must use either the master-secret for the 
+keystore password and key passphrase or choose you own.  If you choose your own passwords, you must 
+use the Knox CLI utility to provide them to the Gateway.  
 
     keytool -importkeystore -srckeystore server.p12 -destkeystore gateway.jks -srcstoretype pkcs12
 
 While using this approach a couple of important things to be aware of:
 
-1. the alias MUST be "gateway-identity". You may need to change it using keytool after the import of the PKCS12 store. You can use keytool to do this - for example: 
+1. The alias MUST be properly set. If it is not the default value ("gateway-identity"), it must be 
+   set in the configuration using `gateway.tls.key.alias`. You may need to change it using keytool 
+   after the import of the PKCS12 store. You can use keytool to do this - for example:
 
         keytool -changealias -alias "1" -destalias "gateway-identity" -keystore gateway.jks -storepass {knoxpw}
     
-2. the name of the expected identity keystore for the gateway MUST be `gateway.jks`
-3. the passwords for the keystore and the imported key may both be set to the master secret for the gateway install. You can change the key passphrase after import using keytool as well. You may need to do this in order to provision the password in the credential store as described later in this section. For example:
+2. The path to the identity keystore for the gateway MUST be the default path 
+   (`{GATEWAY_HOME}/data/security/keystores/gateway.jks`) or MUST be specified in the configuration 
+   using `gateway.tls.keystore.path` and `gateway.tls.keystore.type`  
+3. The passwords for the keystore and the imported key may both be set to the master secret for the 
+   gateway install.  If a custom password is used, the passwords must be imported into the credential 
+   store using the Knox CLI `create-alias` command.  The aliases for the passwords must then be set 
+   in the configuration using `gateway.tls.keystore.password.alias` and `gateway.tls.key.passphrase.alias`.  
+   If both the keystore password and the key passphrase are the same, only `gateway.tls.keystore.password.alias` 
+   needs to be set.  You can change the key passphrase after import using keytool. You may need to 
+   do this in order to provision the password in the credential store as described later in this 
+   section. For example:
 
         keytool -keypasswd -alias gateway-identity -keystore gateway.jks
 
-NOTE: The password for the keystore as well as that of the imported key may be the master secret for the gateway instance or you may set the gateway-identity-passphrase alias using the Knox CLI to the actual key passphrase. See the Knox CLI section for details.
-
-The following will allow you to provision the passphrase for the private key that you set during keystore creation above - it will prompt you for the actual passphrase.
-
-    bin/knoxcli.sh create-alias gateway-identity-passphrase
+The following will allow you to provision the password for the keystore or the passphrase for the 
+private key that was set during keystore creation above - it will prompt you for the actual 
+password/passphrase.
+
+    bin/knoxcli.sh create-alias <alias name>
+
+The default alias for the keystore password is `gateway-identity-keystore-password`, to use a different
+alias, set `gateway.tls.keystore.password.alias` in the configuration. The default alias for the key 
+passphrase is `gateway-identity-keystore-password`, to use a different alias, set 
+`gateway.tls.key.passphrase.alias` in the configuration.
 
 ##### Generating a self-signed cert for use in testing or development environments #####
 
@@ -912,10 +965,10 @@ See the Knox CLI section for description
 ##### Using a CA Signed Key Pair #####
 For certain deployments a certificate key pair that is signed by a trusted certificate authority is required. There are a number of different ways in which these certificates are acquired and can be converted and imported into the Apache Knox keystore.
 
-The following steps have been used to do this and are provided here for guidance in your installation.
-You may have to adjust according to your environment.
-
-General steps:
+###### Option #1 ######
+One way to do this is to install the certificate and keys in the default identity keystore and the 
+master secret.  The following steps have been used to do this and are provided here for guidance in 
+your installation.  You may have to adjust according to your environment.
 
 1. Stop Knox gateway and back up all files in `{GATEWAY_HOME}/data/security/keystores`
 
@@ -951,18 +1004,60 @@ General steps:
 
 8. Restart Knox gateway. Check `gateway.log` to check whether the gateway started properly and clusters are deployed. You can check the timestamp on cluster deployment files
 
+        gateway.sh start
+        ls -alrt {GATEWAY_HOME}/data/deployment
+
+9. Verify that clients can use the CA authority cert to access Knox (which is the goal of using public signed cert) using curl or a web browser which has the CA certificate installed
+
+        curl --cacert PATH_TO_CA_CERT -u tom:tom-password -X GET https://localhost:8443/gateway/sandbox/webhdfs/v1?op=GETHOMEDIRECTORY
+
+###### Option #2 ######
+Another way to do this is to place the CA signed keypair in it's own keystore.  The creation of this
+keystore is out of scope for this document. However, once created, the following steps can be use to
+configure the Knox Gateway to use it. 
+
+1. Move the new keystore into a location that the Knox Gateway can access.
+
+2. Edit the gateway-site.xml file to set the configurations   
+    * `gateway.tls.keystore.password.alias` - Alias of the password for the keystore
+    * `gateway.tls.keystore.path` - Path to the keystore file
+    * `gateway.tls.keystore.type` - Type of keystore file (JKS, JCEKS, PKCS12)
+    * `gateway.tls.key.alias` - Alias for the certificate and key
+    * `gateway.tls.key.passphrase.alias` - Alias of the passphrase for the key 
+      (needed if the passphrase is different than the keystore password)
+
+3. Provision the relevant passwords using the Knox CLI
+
+        knoxcli.sh create-alias <alias> --value <password/passphrase>
+        
+4. Stop Knox gateway
+
+        gateway.sh stop
+       
+5. Restart Knox gateway. Check `gateway.log` to check whether the gateway started properly and 
+   clusters are deployed. You can check the timestamp on cluster deployment files
+
+        gateway.sh start
         ls -alrt {GATEWAY_HOME}/data/deployment
 
-9. Verify that clients can use the CA authority cert to access Knox (which is the goal of using public signed cert) using curl or a web browsers which has the CA certificate installed
+6. Verify that clients can use the CA authority cert to access Knox (which is the goal of using 
+   public signed cert) using curl or a web browsers which has the CA certificate installed
 
         curl --cacert supwin12ad.cer -u hdptester:hadoop -X GET 'https://$fqdn_knox:8443/gateway/$topologyname/webhdfs/v1/tmp?op=LISTSTATUS'
+  
 
 ##### Credential Store #####
-Whenever you provide your own keystore with either a self-signed cert or an issued certificate signed by a trusted authority, you will need to set an alias for the `gateway-identity-passphrase` or create an empty credential store. This is necessary for the current release in order for the system to determine the correct password for the keystore and the key.
+Whenever you provide your own keystore with either a self-signed cert or an issued certificate signed 
+by a trusted authority, you will need to set an alias for the keystore password and key passphrase. 
+This is necessary for the current release in order for the system to determine the correct passwords 
+to use for the keystore and the key.
 
 The credential stores in Knox use the JCEKS keystore type as it allows for the storage of general secrets in addition to certificates.
 
-Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. These aliases are managed within credential stores which are created by the CLI as needed. The simplest approach is to create the `gateway-identity-passphrase` alias with the Knox CLI. This will create the credential store if it doesn't already exist and add the key passphrase.
+Keytool may be used to create credential stores but the Knox CLI section details how to create aliases. 
+These aliases are managed within credential stores which are created by the CLI as needed. The 
+simplest approach is to create the relevant aliases with the Knox CLI. This will create the credential 
+store if it does not already exist and add the password or passphrase.
 
 See the Knox CLI section for descriptions of the command line utilities related to the management of the credential stores.
 



Mime
View raw message