Skip to content

Docs update #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 4 commits into from
May 22, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2,353 changes: 1,279 additions & 1,074 deletions README.md

Large diffs are not rendered by default.

339 changes: 163 additions & 176 deletions docsource/content.md

Large diffs are not rendered by default.

4 changes: 2 additions & 2 deletions docsource/rfder.md
Original file line number Diff line number Diff line change
@@ -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.
6 changes: 4 additions & 2 deletions docsource/rfjks.md
Original file line number Diff line number Diff line change
@@ -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.
6 changes: 4 additions & 2 deletions docsource/rfkdb.md
Original file line number Diff line number Diff line change
@@ -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.
7 changes: 5 additions & 2 deletions docsource/rfora.md
Original file line number Diff line number Diff line change
@@ -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.
9 changes: 6 additions & 3 deletions docsource/rfpem.md
Original file line number Diff line number Diff line change
@@ -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.
10 changes: 5 additions & 5 deletions docsource/rfpkcs12.md
Original file line number Diff line number Diff line change
@@ -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
Loading