Hi James,
On 14.03.24 19:53, James B. Byrne via OpenXPKI-users wrote:
# use ALIAS as key as it makes debug and management easier
ca-signer:
inherit: default
key_store: DATAPOOL
key: "[% ALIAS %]"
In this context: What does "[% ALIAS %]" represent, where is it set, and how is
it used? Is this the realm name? In other words in this instance 'democa'? Is
this value then used to search the RDBMS for the appropriate records?
The alias is the symbolic name of this token which is what you see when
adding the key with the openxpkiadm command to the system, using the
default naming it is "ca-signer-1" for the first issuing token. The
storage method "datapool" refers to the table of the same name and this
is then used as key to load the right item from the DB. The good news is
- if you use the provided CLI tools to load the keys aside with the
certificates, OpenXPKI will resolve the proper name and write the key
blobs to the DB in the right way
Respecting the democa secret, I updated system/crypto.yaml as you suggested and
openxpki webui appeared to function correctly. However, that is not the final
solution given two realms having two separate roots and private keys with
differing passphrase.
By inference it should be possible to override the secret: default in
token:ca-signer simply by replacing it with 'secret: ca-signer'. Given that the
ca-signer block exists and contains the data as given in my previous message.
Therefore, I removed the democa secret from system/crypto.yaml and made the
change described above to the token:ca-signer block in
realm/democa/crypto.yaml. This appears to work although evidently it is not a
suggested solution, for security reasons most likely.
Well - OpenXPKI is quite flexible when it comes to those secrets and
this brings some complexity. The config in the demo setup makes the
assumption that you share one secret across all realms and tokens but as
you already figured out you can easily have one or more secrets and
define them either directly in the realm or use the inheritance to have
them defined globally. Passing a literal secret in the config file is
not really an option for production but there are several other ways how
to inject the secret into the configuration. You can pass the values via
ENV or use a "symlink" to a dedicated password file / daemon or as
Martin already mentioned let the operator provide the secret manually.
I infer from these results that each realm/<name>/crypto.yaml can be
individually configured to hold the private key decryption passphrase specific
to the private key for that realm's issuing CA. Am I correct?
yes :)
Oliver
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
