James, > openxpkiadm alias \ > --realm "hll_ca2016" \ > --token certsign \ > --file /CA_HLL_ROOT_2016/certs/02.pem \ > --key /CA_HLL_ROOT_2016/private/keys/02.key.aes256
This command - imported 02.pem as the first (a "--generation 1" is implicit when you import the very first token) signer token in realm hll_ca2016 - also imported 02.key.aes as the corresponding signer key for this token The system automatically created the signer token ca-signer-1 as one instance of the ca-signer token group. You can import additional signers a few years down the road to perform seamless CA rollovers in your realm, if you don't specify --generation they will be assigned the token aliases ca-signer-2, ca-signer-3 etc. > This is what I have in crypto.yaml ... > token: > default: > backend: OpenXPKI::Crypto::Backend::OpenSSL > > # Template to create key, available vars are > # ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) > # KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem ... > > # Default value for import, recorded in database, can be overriden > secret: default > > ca-signer: > inherit: default > key_store: DATAPOOL > key: "[% ALIAS %]" > > > I infer from this error message: > > 2024/03/22 08:58:12 ERROR I18N_OPENXPKI_TOOLKIT_COMMAND_FAILED; __COMMAND__ => > OpenXPKI::Crypto::Backend::OpenSSL::Command::pkcs7_sign, __ERRVAL__ => > I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__ => cms -sign -binary > -nosmimecap -outform PEM -nodetach -in /var/tmp/openxpki7068rAhBRK43 -inkey > /var/tmp/openxpki7068HnLhAvaK/ca-signer-1 -signer > /var/tmp/openxpki7068wnbNYH_K > -out /var/tmp/openxpki7068BT1d_Hs4 -passin env:pwd, __EXIT_STATUS__ => 512 > [pid=7068|sid=IBVP] > > That the issue lies in the configuration of crypto.yaml. No, it indicates that the secret group "default" does not unlock the CA key for ca-signer-1 in the datapool. > I do not grasp the employment of tokens. The error message refers to > ca-signer-1. Is this a token name? If so, does it have to be explicitly > named > in crypto.yaml or does the openxpki software look for ca-signer? See above. ca-signer is the token group. ca-signer-1 is a token instance in this token group. > Assuming that ca-signer is searched for then what is the value returned by "[% > ALIAS %]"? Does this reference get used to SEARCH in the RDBMS? What is > returned? The key itself or the path to the key file? Maybe we did not explain this properly in one of the previous posts. In your config > key_store: DATAPOOL > key: "[% ALIAS %]" tells the system to look in the datapool and retrieve the private key by its alias from the datapool. During the import of the private key in the above openxpkiadm command the private key was read and stored in the datapool. This is not mandatory, if it confuses you it can also be placed in the file system. In that case simply don't override key_store in the ca_signer definition, and the key will be referenced from the default location specified in token.default. > When the 'openxpkiadm alias' command receives the '--key > /CA_HLL_ROOT_2016/private/keys/02.key.aes256' argument are the contents of > that > file stored in the DB or the path to the key file? Depends on the token configuration. If key_store: DATAPOOL is set, the key is stored in the datapool. If key_store: OPENXPKI is set, the key is referenced from the file system. You can deposit they key in the file system yourself (and leave out --key during import) or have openxpkiadm write the key to the file system. Cheers Martin _______________________________________________ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
