Hi Oliver,
That seems an interesting feature, will keep it in mind. If our current
use case is successful enough we might have some room to market the
product internally for bigger use cases and possibly opt for enterprise
demo at the same time :)
Br,
Pekka
On 23/05/2024 15:58, Oliver Welter wrote:
Hi Pekka,
the EE version comes with a nice "Key Escrow" module - so if you need
something in this direction it might be worth to evaluate our
enterprise packages ;)
best regards
Oliver
On 23.05.24 14:18, Pekka Länsiaho wrote:
Hi again,
I will give this a go maybe tomorrow, it seems like a logical change
so maybe wont need further help but will come back if something
doesn't work.
You are right that it is generally not a good idea to do this, but
our particular use case requires us to forgo some general best
practices and the risks have all been acknowledged. At least with
this product we have somewhat simple way of making changes on the fly
so we can revert back to more secure workflows if there is need for
them :)
Thanks,
Pekka
On 23/05/2024 13:01, Oliver Welter wrote:
Hi Pekka,
having the same password for all certificates is a security risk but
I think you have your reason to do so...
The best approach ist to change the action "retype_server_password"
to be of the class "Tools::SetContext" and set the password from there.
class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext
param:
_password: mysupersecretpassword
You also might want to rework the workflow graph to autorun this.
best regards
Oliver
On 23.05.24 09:49, Pekka Länsiaho wrote:
Hello,
What is the most correct way to set a static password for all
certificates generated by the default
certificate_signing_request_v2.yaml workflow?
I have tried adjusting the workflow to run generate_key and skip
straight to KEY_GENERATED as well as NOTIFY_CSR_PENDING steps from
SUBJECT_COMPLETE while setting the password string in _map_password
param of generate_key, and running all the intermediate functions
in SUBJECT_COMPLETE.. However all of my attempts seem to cause the
workflow to fail at one stage or another.
Ideally we would like to see the workflow go from 'Review Request'
step directly to 'Certificate issued' on the interactive signing
request while still retaining the policy exception process to avoid
duplicate certificates being issued.
Thanks in advance.
Best regards,
Pekka
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users