Docs update (#81)

* chore(docs): Reformat docs, fix grammar and spelling mistakes, and a lot of opinionated format changes.

* Update generated docs

---------

Co-authored-by: Keyfactor <[email protected]>

Author: spbsoluble

README.md

@@ -1,7 +1,7 @@
 ## Overview
 
-The RFDER store type can be used to manage DER encoded files.
+The `RFDER` store type can be used to manage DER encoded files.
 
-Use cases supported:
+### Supported use cases
 1. Single certificate stores with private key in an external file.
 2. Single certificate stores with no private key.

docsource/content.md

@@ -1,8 +1,10 @@
 ## Overview
 
-The RFJKS store type can be used to manage java keystores of types JKS or PKCS12.  If creating a new java keystore and adding a certificate all via Keyfactor Command, the created java keystore will be of type PKCS12, as java keystores of type JKS have been deprecated as of JDK 9.
+The `RFJKS` store type can be used to manage java keystores of types `JKS` or `PKCS12`.  If creating a new java keystore 
+and adding a certificate all via Keyfactor Command, the created java keystore will be of type `PKCS12`, as java keystores 
+of type `JKS` have been deprecated as of `JDK 9`.
 
-Use cases supported:
+### Supported use cases
 1. One-to-many trust entries - A trust entry is defined as a single certificate without a private key in a certificate store.  Each trust entry is identified with a custom alias.
 2. One-to-many key entries - One-to-many certificates with private keys and optionally the full certificate chain.  Each certificate is identified with a custom alias.
 3. A mix of trust and key entries.

docsource/rfder.md

@@ -1,8 +1,10 @@
 ## Overview
 
-The RFKDB store type can be used to manage IBM Key Database Files (KDB) files.  The IBM utility, GSKCAPICMD, is used to read and write certificates from and to the target store and is therefore required to be installed on the server where each KDB certificate store being managed resides, and its location MUST be in the system $Path.
+The `RFKDB` store type can be used to manage IBM Key Database Files (`KDB`) files.  The IBM utility, `GSKCAPICMD`, is used 
+to read and write certificates from and to the target store and is therefore required to be installed on the server where 
+each `KDB` certificate store being managed resides, and its location MUST be in the system `$Path`.
 
-Use cases supported:
+### Supported use cases
 1. One-to-many trust entries - A trust entry is defined as a single certificate without a private key in a certificate store.  Each trust entry is identified with a custom alias.
 2. One-to-many key entries - One-to-many certificates with private keys and optionally the full certificate chain.  Each certificate is identified with a custom alias.
 3. A mix of trust and key entries.

docsource/rfjks.md

@@ -1,8 +1,11 @@
 ## Overview
 
-The RFORA store type can be used to manage Pkcs12 Oracle Wallets.  Please note that while this should work for Pkcs12 Oracle Wallets installed on both Windows and Linux servers, this has only been tested on wallets installed on Windows.  Please note, when entering the Store Path for an Oracle Wallet in Keyfactor Command, make sure to INCLUDE the eWallet.p12 file name that by convention is the name of the Pkcs12 wallet file that gets created.
+The `RFORA` store type can be used to manage `PKCS12` Oracle Wallets. 
 
-Use cases supported:
+> NOTE: This should work for `PKCS12` Oracle Wallets installed on both Windows and Linux servers, this has only been tested on wallets installed on Windows.  
+> NOTE: When entering the Store Path for an Oracle Wallet in Keyfactor Command, make sure to INCLUDE the `eWallet.p12` file name that by convention is the name of the `PKCS12` wallet file that gets created.
+
+### Supported use cases
 1. One-to-many trust entries - A trust entry is defined as a single certificate without a private key in a certificate store.  Each trust entry is identified with a custom alias.
 2. One-to-many key entries - One-to-many certificates with private keys and optionally the full certificate chain.  Each certificate is identified with a custom alias.
 3. A mix of trust and key entries.

docsource/rfkdb.md

@@ -1,12 +1,15 @@
 ## Overview
 
-The RFPEM store type can be used to manage PEM encoded files.
+The `RFPEM` store type can be used to manage `PEM` encoded files.
 
-Use cases supported:
+### Supported use cases
 1. Trust stores - A file with one-to-many certificates (no private keys, no certificate chains).
 2. Single certificate stores with private key in the file.
 3. Single certificate stores with certificate chain and private key in the file.
 4. Single certificate stores with private key in an external file.
 5. Single certificate stores with certificate chain in the file and private key in an external file
 
-NOTE: PEM stores may only have one private key (internal or external) associated with the store, as only one certificate/chain/private key combination can be stored in a PEM store supported by RFPEM.  Private keys will be stored in encrypted or unencrypted PKCS#8 format (BEGIN [ENCRYPTED] PRIVATE KEY) based on the Store Password set on the Keyfactor Command Certificate Store unless managing a PEM store that currently contains a private key in PKCS#1 format (BEGIN RSA PRIVATE KEY or BEGIN EC PRIVATE KEY).  Store password MUST be set to "No Password" if managing a store with a PKCS#1 private key, as encrypted PKCS#1 keys are not supported with this integration. 
+### Additional Considerations and Limitations
+- `PEM` stores may only have one private key (internal or external) associated with the store, as only one certificate/chain/private key combination can be stored in a PEM store supported by `RFPEM`. 
+- Private keys will be stored in encrypted or unencrypted `PKCS#8` format (`BEGIN [ENCRYPTED] PRIVATE KEY`) based on the Store Password set on the Keyfactor Command Certificate Store unless managing a `PEM` store that currently contains a private key in `PKCS#1` format (`BEGIN RSA PRIVATE KEY` or `BEGIN EC PRIVATE KEY`). 
+- Store password *MUST* be set to `No Password` if managing a store with a `PKCS#1` private key, as encrypted `PKCS#1` keys are not supported with this integration. 

docsource/rfora.md

@@ -1,13 +1,13 @@
 ## Overview
 
-The RFPkcs12 store type can be used to manage any PKCS#12 compliant file format INCLUDING java keystores of type PKCS12.
+The `RFPkcs12` store type can be used to manage any `PKCS#12` compliant file format INCLUDING java keystores of type `PKCS12`.
 
-Use cases supported:
-1. One-to-many trust entries -  A trust entry is defined as a single certificate without a private key in a certificate store.  Each trust entry MUST BE identified with a custom friendly name/alias.
+### Supported use cases
+1. One-to-many trust entries - A trust entry is defined as a single certificate without a private key in a certificate store.  Each trust entry MUST BE identified with a custom friendly name/alias.
 2. One-to-many key entries - One-to-many certificates with private keys and optionally the full certificate chain.  Each certificate MUST BE identified with a custom friendly name/alias.
 3. A mix of trust and key entries.  Each entry MUST BE identified with a custom friendly name/alias.
 4. Single certificate stores with a blank/missing friendly name/alias.  Any management add job will replace the current certificate entry and will keep the friendly name/alias blank.  The Keyfactor Command certificate store will show the current certificate thumbprint as the entry's alias.
 
-Use cases not supported:
-1. Multiple key and/or trust entries with a mix of existing and non existing friendly names/aliases.
+### Unsupported use cases
+1. Multiple key and/or trust entries with a mix of existing and non-existing friendly names/aliases.
 2. Multiple key and/or trust entries with blank friendly names/aliases