Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
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//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
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
On Wed, March 13, 2024 18:00, Martin Bartosch wrote: > Hi James, . . . > > > Yep, that's the problem. In the original default crypto.yaml we find > > ... > # The actual token setup > token: > default: > ... ># Default value for import, recorded in database, can be overriden >secret: default > ... > > # 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? 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. I infer from these results that each realm//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? Thank you for the help. It was immensely useful. Regards, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to privacy Do NOT open attachments nor follow links sent by e-Mail James B. Byrnemailto:byrn...@harte-lyne.ca Harte & Lyne Limited http://www.harte-lyne.ca 9 Brockley Drive vox: +1 905 561 1241 Hamilton, Ontario fax: +1 905 561 0757 Canada L8E 3C3 ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > This is the diff between the current config.d and the original before any > changes were made. > > # git diff -G. hllv1.00 -- --follow config.d > diff --git a/config.d/realm.tpl/crypto.yaml b/config.d/realm.tpl/crypto.yaml > index 95614f5..bda48a1 100644 > --- a/config.d/realm.tpl/crypto.yaml > +++ b/config.d/realm.tpl/crypto.yaml > @@ -15,7 +15,8 @@ token: ># Template to create key, available vars are ># ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) ># KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > -key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > ># possible values are OpenSSL, nCipher, LunaCA >engine: OpenSSL > @@ -42,7 +43,8 @@ token: > > vault: >inherit: default > -key: /etc/openxpki/local/keys/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% ALIAS %].pem > > ratoken: >inherit: default > @@ -58,6 +60,13 @@ token: > > # Define the secret groups > secret: > + > +ca-signer: > +label: Secret group for certsign Token > +export: 1 > +method: literal > +value: "democa" > + >default: ># this let OpenXPKI use the secret of the same name from system.crypto ># if you do not want to share the secret just replace this line with > @@ -69,4 +78,4 @@ secret: >label: Secret group for RA Token >export: 1 >method: literal > -value: root > \ No newline at end of file > +value: root Yep, that's the problem. In the original default crypto.yaml we find ... # The actual token setup token: default: ... # Default value for import, recorded in database, can be overriden secret: default ... # use ALIAS as key as it makes debug and management easier ca-signer: inherit: default key_store: DATAPOOL key: "[% ALIAS %]" ... # Define the secret groups secret: default: # this let OpenXPKI use the secret of the same name from system.crypto # if you do not want to share the secret just replace this line with # the config found in system.crypto. You can create additional secrets # by adding similar blocks with another key import: 1 This means that the ca-signer token inherits from the default token configuration which references the "default" secret group. This "default" secret group is imported from the global configuration in config.d/system/crypto.yaml. There we find: secret: default: label: Global secret group export: 0 method: literal value: root You added a new literal secret group "ca-signer" with the value "democa" to your token configuration. Now, the error in the configuration is that you obviously assumed that by defining a secret group with the same name as the signer token will link this. This is not the case. Your new secret group was defined but is never used. In order to make this work as you intend you need to do one of the following: 1. in your default token configuration change the secret definition to the correct secret group reference: token: default: ... secret: ca-signer OR 2. change the password in the "default" secret group from "root" to "democa" OR 3. change the CA key passphrase to "root" OR 3. enable passphrase entry via the GUI and use the GUI to enter your passphrase "democa" after startup Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > This is the diff between the current config.d and the original before any > changes were made. > > # git diff -G. hllv1.00 -- --follow config.d > diff --git a/config.d/realm.tpl/crypto.yaml b/config.d/realm.tpl/crypto.yaml > index 95614f5..bda48a1 100644 > --- a/config.d/realm.tpl/crypto.yaml > +++ b/config.d/realm.tpl/crypto.yaml > @@ -15,7 +15,8 @@ token: > # Template to create key, available vars are > # ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) > # KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) > -key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem > > # possible values are OpenSSL, nCipher, LunaCA > engine: OpenSSL > @@ -42,7 +43,8 @@ token: > > vault: > inherit: default > -key: /etc/openxpki/local/keys/[% ALIAS %].pem > +# key: /etc/openxpki/local/keys/[% ALIAS %].pem > +key: /usr/local/etc/openxpki/local/keys/[% ALIAS %].pem > > ratoken: > inherit: default > @@ -58,6 +60,13 @@ token: > > # Define the secret groups > secret: > + > +ca-signer: > +label: Secret group for certsign Token > +export: 1 > +method: literal > +value: "democa" > + > default: > # this let OpenXPKI use the secret of the same name from system.crypto > # if you do not want to share the secret just replace this line with > @@ -69,4 +78,4 @@ secret: > label: Secret group for RA Token > export: 1 > method: literal > -value: root > \ No newline at end of file > +value: root Yep, that's the problem. In the original default crypto.yaml we find ... # The actual token setup token: default: ... # Default value for import, recorded in database, can be overriden secret: default ... # use ALIAS as key as it makes debug and management easier ca-signer: inherit: default key_store: DATAPOOL key: "[% ALIAS %]" ... # Define the secret groups secret: default: # this let OpenXPKI use the secret of the same name from system.crypto # if you do not want to share the secret just replace this line with # the config found in system.crypto. You can create additional secrets # by adding similar blocks with another key import: 1 This means that the ca-signer token inherits from the default token configuration which references the "default" secret group. This "default" secret group is imported from the global configuration in config.d/system/crypto.yaml. There we find: secret: default: label: Global secret group export: 0 method: literal value: root You added a new literal secret group "ca-signer" with the value "democa" to your token configuration. Now, the error in the configuration is that you obviously assumed that by defining a secret group with the same name as the signer token will link this. This is not the case. Your new secret group was defined but is never used. In order to make this work as you intend you need to do one of the following: 1. in your default token configuration change the secret definition to the correct secret group reference: token: default: ... secret: ca-signer OR 2. change the password in the "default" secret group from "root" to "democa" OR 3. change the CA key passphrase to "root" OR 3. enable passphrase entry via the GUI and use the GUI to enter your passphrase "democa" after startup Cheers Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
On Wed, March 13, 2024 09:25, Martin Bartosch wrote: > Hi James, > . . . > > 1. the output of openxpkicli get_token_info (file in file system) is not > consistent with your configuration (key in datapool). I have no idea why, > because I cannot see more details on your system, but to me it looks like the > ca-signer token configuration is not the config the system is using > > 2. the config snippet is missing the definition for "default" in crypto.yaml > where I assume the secret group is defined. If that does not match the secret > group you seemingly intend to use for your ca signer tokens (which you named > "ca-signer") then the passphrase will not be set correctly. Again, without > being able to see more or your config it is impossible to tell. This is the diff between the current config.d and the original before any changes were made. # git diff -G. hllv1.00 -- --follow config.d diff --git a/config.d/realm.tpl/crypto.yaml b/config.d/realm.tpl/crypto.yaml index 95614f5..bda48a1 100644 --- a/config.d/realm.tpl/crypto.yaml +++ b/config.d/realm.tpl/crypto.yaml @@ -15,7 +15,8 @@ token: # Template to create key, available vars are # ALIAS (ca-signer-1), GROUP (ca-signer), GENERATION (1) # KEY_IDENTIFIER (00:AA:BB...), IDENTIFIER (aGSNY1Z...) -key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem +# key: /etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem +key: /usr/local/etc/openxpki/local/keys/[% PKI_REALM %]/[% ALIAS %].pem # possible values are OpenSSL, nCipher, LunaCA engine: OpenSSL @@ -42,7 +43,8 @@ token: vault: inherit: default -key: /etc/openxpki/local/keys/[% ALIAS %].pem +# key: /etc/openxpki/local/keys/[% ALIAS %].pem +key: /usr/local/etc/openxpki/local/keys/[% ALIAS %].pem ratoken: inherit: default @@ -58,6 +60,13 @@ token: # Define the secret groups secret: + +ca-signer: +label: Secret group for certsign Token +export: 1 +method: literal +value: "democa" + default: # this let OpenXPKI use the secret of the same name from system.crypto # if you do not want to share the secret just replace this line with @@ -69,4 +78,4 @@ secret: label: Secret group for RA Token export: 1 method: literal -value: root \ No newline at end of file +value: root diff --git a/config.d/system/database.yaml b/config.d/system/database.yaml old mode 100644 new mode 100755 index 472217a..3043863 --- a/config.d/system/database.yaml +++ b/config.d/system/database.yaml @@ -1,9 +1,9 @@ main: debug: 0 -type: MariaDB +type: PostgreSQL name: openxpki host: localhost -port: 3306 +port: 5432 user: openxpki passwd: openxpki diff --git a/config.d/system/realms.yaml b/config.d/system/realms.yaml old mode 100644 new mode 100755 index 9b0036b..bc50e30 --- a/config.d/system/realms.yaml +++ b/config.d/system/realms.yaml @@ -4,3 +4,7 @@ democa: label: Example.org Demo CA baseurl: https://pki.example.com/openxpki/ + +hll_ca2016: +label:Harte & Lyne Limited CA +baseurl: https://openxpki-3.internal.harte-lyne.ca/openxpki/ diff --git a/config.d/system/server.yaml b/config.d/system/server.yaml old mode 100644 new mode 100755 index e667f0f..2b4d741 --- a/config.d/system/server.yaml +++ b/config.d/system/server.yaml @@ -1,19 +1,20 @@ # Shown in the processlist to distinguish multiple instances -name: main +name: hll_main # Location of the log4perl configuration -log4perl: /etc/openxpki/log.conf +#log4perl: /etc/openxpki/log.conf +log4perl: /usr/local/etc/openxpki/log.conf # Daemon settings user: openxpki group:openxpki socket_file: /var/openxpki/openxpki.socket -pid_file: /run/openxpkid.pid +pid_file: /var/run/openxpkid.pid stderr: /var/log/openxpki/stderr.log tmpdir: /var/tmp # we need to give write permission to the socket for the webserver -socket_owner: www-data +socket_owner: www # This is experimental! #type: PreFork > > 2a. a fixed value for a CA key is not a good idea True, On the other hand this is a proof of concept test and literal values allow one to grep for things. > > Bottom line: your system cannot access the private key, and this is either a > permission problem or a problem with the CA passphrase. The passphrase has been verified as correct as I can expose the private key using openssl. The service script provided with the pr-openxpki pkg from FreeBSD ports trashes the permissions and ownerships. I ran that instead of openxpkictl (once) and discovered that the hard way. So a permissions problem is possible. On the other hand I have just completed a thorough check of file permissions against those in the community branch and these are all the same. Thanks, -- *** e-Mail is NOT a SECURE channel *** Do NOT transmit sensitive data via e-Mail Unencrypted messages have no legal claim to
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James,
> 2024/03/13 08:16:31 ERROR OpenSSL error: Using configuration from
> /var/tmp/openxpki28821VniVdpfp/openssl.cnf
> unable to load CA private key
> . . .
>
> I guess that this is the problem: unable to load CA private key
Yep.
> The realm was created using:
>
> openxpkiadm alias \
> --realm "democa" \
> --token certsign\
> --file
> /root/CLCA/CAS/democa/certs/1A84E8FBE282453D5F22038C58A89786BCD6CCAC.pem \
> --key /root/CLCA/CAS/democa_i/private/democa_i_key.pem
>
> openxpkicli get_token_info --realm=democa --arg alias=vault-1
> {
> "key_name" : "/usr/local/etc/openxpki/local/keys/vault-1.pem",
> "key_secret" : 1,
> "key_store" : "OPENXPKI",
> "key_usable" : 1
> }
>
> I have verified that the private key password provided in
> config/realm/democa/crypto.yaml is correct:
>
> . .
> ca-signer:
>inherit: default
>key_store: DATAPOOL
>key: "[% ALIAS %]"
> . . .
> secret:
>
>ca-signer:
>label: Secret group for certsign Token
>export: 1
>method: literal
>value: "democa"
1. the output of openxpkicli get_token_info (file in file system) is not
consistent with your configuration (key in datapool). I have no idea why,
because I cannot see more details on your system, but to me it looks like the
ca-signer token configuration is not the config the system is using
2. the config snippet is missing the definition for "default" in crypto.yaml
where I assume the secret group is defined. If that does not match the secret
group you seemingly intend to use for your ca signer tokens (which you named
"ca-signer") then the passphrase will not be set correctly. Again, without
being able to see more or your config it is impossible to tell.
2a. a fixed value for a CA key is not a good idea
Bottom line: your system cannot access the private key, and this is either a
permission problem or a problem with the CA passphrase.
Cheers
Martin
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
On Wed, March 13, 2024 07:52, Martin Bartosch wrote:
> Hi James,
. . .
>
> You should get more information about the error in the openxpki.log file. I
> suspect something is wrong with the CSR or the CA key, but the details you
> posted do not contain sufficient detail to tell what exactly went wrong.
]# tail -15 /var/log/openxpki/openxpki.log
30356799270912:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad
decrypt:/usr/src/crypto/openssl/crypto/evp/evp_enc.c:612:
30356799270912:error:0906A065:PEM routines:PEM_do_header:bad
decrypt:/usr/src/crypto/openssl/crypto/pem/pem_lib.c:461:
[pid=28821|sid=Xo3x]
2024/03/13 08:16:05 ERROR I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__
=> cms -sign -binary -nosmimecap -outform PEM -nodetach -in
/var/tmp/openxpki2882150mH98yQ -inkey
/var/tmp/openxpki28821I21Uh1bg/ca-signer-1 -signer
/var/tmp/openxpki28821N0I0U0Uk -out /var/tmp/openxpki28821zjQtwDW0 -passin
env:pwd, __EXIT_STATUS__ => 512 [pid=28821|sid=Xo3x]
2024/03/13 08:16:05 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/openxpki2882150mH98yQ -inkey
/var/tmp/openxpki28821I21Uh1bg/ca-signer-1 -signer
/var/tmp/openxpki28821N0I0U0Uk -out /var/tmp/openxpki28821zjQtwDW0 -passin
env:pwd, __EXIT_STATUS__ => 512 [pid=28821|sid=Xo3x]
2024/03/13 08:16:31 ERROR OpenSSL error: Using configuration from
/var/tmp/openxpki28821VniVdpfp/openssl.cnf
unable to load CA private key
. . .
I guess that this is the problem: unable to load CA private key
The realm was created using:
openxpkiadm alias \
--realm "democa" \
--token certsign\
--file
/root/CLCA/CAS/democa/certs/1A84E8FBE282453D5F22038C58A89786BCD6CCAC.pem \
--key /root/CLCA/CAS/democa_i/private/democa_i_key.pem
openxpkicli get_token_info --realm=democa --arg alias=vault-1
{
"key_name" : "/usr/local/etc/openxpki/local/keys/vault-1.pem",
"key_secret" : 1,
"key_store" : "OPENXPKI",
"key_usable" : 1
}
I have verified that the private key password provided in
config/realm/democa/crypto.yaml is correct:
. .
ca-signer:
inherit: default
key_store: DATAPOOL
key: "[% ALIAS %]"
. . .
secret:
ca-signer:
label: Secret group for certsign Token
export: 1
method: literal
value: "democa"
openssl rsa \
-noout \
-text \
-in /root/CLCA/CAS/democa_i/private/democa_i_key.pem
Enter pass phrase for /root/CLCA/CAS/democa_i/private/democa_i_key.pem:
RSA Private-Key: (4096 bit, 2 primes)
modulus:
>
> Is your CA set up correctly? Are you able to create a CRL?
# openxpkicmd --realm democa crl_issuance
Workflow created (ID: 1791), State: LOAD_NEXT_CA_CRL_GET_NEXT_CA_0
# openxpkicmd --realm hll_ca2016 crl_issuance
Workflow created (ID: 2047), State: LOAD_NEXT_CA_CRL_GET_NEXT_CA_0
What is wrong with my setup?
Thanks,
--
*** e-Mail is NOT a SECURE channel ***
Do NOT transmit sensitive data via e-Mail
Unencrypted messages have no legal claim to privacy
Do NOT open attachments nor follow links sent by e-Mail
James B. Byrnemailto:byrn...@harte-lyne.ca
Harte & Lyne Limited http://www.harte-lyne.ca
9 Brockley Drive vox: +1 905 561 1241
Hamilton, Ontario fax: +1 905 561 0757
Canada L8E 3C3
___
OpenXPKI-users mailing list
OpenXPKI-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openxpki-users
Re: [OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
Hi James, > __EXIT_STATUS__ => 256 == Searching for Openssl error codes the number 256 > comes up as related to an unsupported cipher. Where is the cypher being > specified? The exit status is shifted left by 8 bit by the execution wrapper in OpenXPKI, so the actual return code is 256 >> 8 == 1, and 1 is the generic OpenSSL error message. You should get more information about the error in the openxpki.log file. I suspect something is wrong with the CSR or the CA key, but the details you posted do not contain sufficient detail to tell what exactly went wrong. Is your CA set up correctly? Are you able to create a CRL? Best regards, Martin ___ OpenXPKI-users mailing list OpenXPKI-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openxpki-users
[OpenXPKI-users] Unexpected error This workflow was interrupted by an unexpected event
I am working with democa and tried to sign a csr. However I get this error: Unexpected error This workflow was interrupted by an unexpected event, it will not continue without a manual interaction. Please contact the support team! The csr was generated using: openssl x509 -x509toreq -signkey /usr/local/etc/pki/tls/private/ca.harte-lyne.ca.key -in /usr/local/etc/pki/tls/certs/ca.harte-lyne.ca.pem -out /usr/local/etc/pki/tls/private/ca.harte-lyne.ca.x509.csr Tail /var/log/openxpki/workflows.log shows this: . . . 2024/03/12 15:13:55 1535 Trigger notification message csr_created 2024/03/12 15:14:04 1535 Unsigned approval for workflow 1535 by user rob, role RA Operator 2024/03/12 15:14:04 1535 Trigger notification message csr_notify_approval 2024/03/12 15:14:04 1535 persisted csr for CN=ca.harte-lyne.ca,DC=Test Deployment,DC=OpenXPKI,DC=org with csr_serial 255 2024/03/12 15:14:04 1535 start cert issue for serial 255, workflow 1535 2024/03/12 15:14:04 1535 NICE backend error: I18N_OPENXPKI_TOOLKIT_COMMAND_FAILED; __COMMAND__ => OpenXPKI::Crypto::Backend::OpenSSL::Command::issue_cert, __ERRVAL__ => I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__ => ca -batch -subj /DC=org/DC=OpenXPKI/DC=Test Deployment/CN=ca.harte-lyne.ca -out /var/tmp/openxpki63855kHieUFAv -in /var/tmp/openxpki63855rE2mXQyn -passin env:pwd, __EXIT_STATUS__ => 256 2024/03/12 15:14:04 1535 NICE issueCertificate failed but pause_on_error is requested 2024/03/12 15:14:04 1535 Action global_nice_issue_certificate paused (I18N_OPENXPKI_UI_NICE_BACKEND_ERROR), wakeup 2024-03-12T19:18:40 tail -6 /var/log/openxpki/catchall.log 2024/03/12 16:00:47 OpenXPKI.Server.Workflow.ERROR Caught exception from action: [Generic exception]; reset workflow to old state 'APPROVED_GLOBAL_PERSIST_CSR_0' [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] [root@openxpki-3 openxpki (hll_ca2016)]# tail -6 /var/log/openxpki/catchall.log 2024/03/12 16:00:47 openxpki.system.ERROR I18N_OPENXPKI_TOOLKIT_COMMAND_FAILED; __COMMAND__ => OpenXPKI::Crypto::Backend::OpenSSL::Command::issue_cert, __ERRVAL__ => I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__ => ca -batch -subj /DC=org/DC=OpenXPKI/DC=Test Deployment/CN=ca.harte-lyne.ca -out /var/tmp/openxpki64685qlCmpRFy -in /var/tmp/openxpki64685mLitkxVt -passin env:pwd, __EXIT_STATUS__ => 256 [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] 2024/03/12 16:00:47 openxpki.application.ERROR NICE backend error: I18N_OPENXPKI_TOOLKIT_COMMAND_FAILED; __COMMAND__ => OpenXPKI::Crypto::Backend::OpenSSL::Command::issue_cert, __ERRVAL__ => I18N_OPENXPKI_CRYPTO_CLI_EXECUTE_FAILED; __COMMAND__ => ca -batch -subj /DC=org/DC=OpenXPKI/DC=Test Deployment/CN=ca.harte-lyne.ca -out /var/tmp/openxpki64685qlCmpRFy -in /var/tmp/openxpki64685mLitkxVt -passin env:pwd, __EXIT_STATUS__ => 256 [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] 2024/03/12 16:00:47 openxpki.application.WARN NICE issueCertificate failed but pause_on_error is requested [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] 2024/03/12 16:00:47 openxpki.workflow.ERROR Workflow 1535/certificate_signing_request_v2/APPROVED_GLOBAL_PERSIST_CSR_0 retry_exceeded [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] 2024/03/12 16:00:47 openxpki.application.WARN Retry exceeded on action global_nice_issue_certificate [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] 2024/03/12 16:00:47 OpenXPKI.Server.Workflow.ERROR Caught exception from action: [Generic exception]; reset workflow to old state 'APPROVED_GLOBAL_PERSIST_CSR_0' [pid=64685|user=rob|role=RA Operator|sid=/uxI|wftype=certificate_signing_request_v2|wfid=1535] I see this in ./config.d/system/crypto.yaml "shell: /usr/bin/openssl" and command -v openssl gives this result: "/usr/bin/openssl". I am using 'OpenSSL 1.1.1t-freebsd 7 Feb 2023' on FreeBSd-13.2p9. __EXIT_STATUS__ => 256 == Searching for Openssl error codes the number 256 comes up as related to an unsupported cipher. Where is the cypher being specified? # "openssl ciphers" reports these:
