openxpki-users — General discussions about managing OpenXPKI instances (incl. security alerts)

Re: [OpenXPKI-users] Webui unable to communicate with backend after upgrade

[Pekka L. <pek...@gm...>]

Hello,

I ruled out the browser cookie by trying out different browsers and
incognito mode. Results are mostly the same, but there was no SessionCookie
error in webui.log.
After that, I went through the socket settings again, just in case, but
couldn't pinpoint a leftover setting anywhere. Then I walked back the whole
install process and lo-and-behold: Even a demo / sampleconfig fresh install
is no different. I deleted mariadb database, /var/log/openxpki*
-directories and /etc/openxpki -directory, reinstalled debian packages,
rebuilt schemas and ran sampleconfig.sh after the initial setup steps from
debian quickstart section -- And I still get the same result, albeit now I
have nothing indicating an error in logs, since the
earlier /var/log/openxpki/webui.log no longer exists by default.

I will fire up a fresh debian VM and see if I can replicate the behaviour,
but other ideas are welcome in the meantime.

Also, let me ask just in case: Did you provide tools for easier upgrade to
3.32 in enterprise environments? If the experience is better there, I might
have something to discuss with our mr. moneybags :)

best regards,
Pekka


On Mon, Apr 20, 2026 at 7:30 PM Oliver Welter <ma...@ol...> wrote:

> Hi Pekka,
>
> did you try to clear your browser cookies? This sounds a bit like you have
> changed the settings for the session management and now the system tries to
> decode/decrypt stuff from an older session/setting.
>
> Oliver
> On 4/17/26 11:27, Pekka Länsiaho wrote:
>
> Hello again,
>
> We have been a bit slow with the system updates, and since v3.32 was a
> breaking change we had to put off updates entirely for a while, so I am
> trying to remediate that now.
> I have managed to upgrade configuration following instructions in the
> change log
> https://openxpki.readthedocs.io/en/master/upgrading.html#release-v3-32,
> and got both server and client services running after upgrade to v3.32.15
> and using community config v3.32.8. (Old system version was v3.30.9, not
> quite sure which config version, but I believe the community branch commit
> was 17b96e5)
> System is running Debian 12.13.
>
> *openxpkictl status server* and *client* both report running and
> accepting requests, and both clients and serviced logs have no indication
> of errors.
>
> However, when accessing webui at
> https://openxpki/webui/index/#/openxpki/welcome, application error
> appears: "*The webserver did not return the expected data. Possible
> causes: OpenXPKI client is not running; authentication session has expired;
> an internal error. HTTP code: 503*".
>
> And upon inspecting /var/log/openxpki/webui.log, I am met with these lines:
> *ERR Unable to decrypt cookie (AES: Data size must be multiple of
> blocksize (16 bytes) at /usr/share/perl5/Crypt/CBC.pm line 492.) at
> /usr/share/perl5/OpenXPKI/Client/Service/WebUI/SessionCookie.pm line 214.*
> *ERR Error creating backend client: Unable to connect to socket [sid=....]*
> *ERR Backend service is not reachable or not responding [sid=....]*
>
> I tried to look at the newly provided 'sampleconfig.sh' file to see if
> there was a step I might have missed compared to a fresh system install,
> but couldn't immediately point to any particular step, unfortunately.
>
> Help would be much appreciated, my eyes grow tired of comparing things.
>
>
> best regards,
> Pekka
>
>
> _______________________________________________
> OpenXPKI-users mailing lis...@li...://lists.sourceforge.net/lists/listinfo/openxpki-users
>
> --
> Protect your environment -  close windows and adopt a penguin!
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>

Re: [OpenXPKI-users] Webui unable to communicate with backend after upgrade

[Oliver W. <ma...@ol...>]

Hi Pekka,

did you try to clear your browser cookies? This sounds a bit like you 
have changed the settings for the session management and now the system 
tries to decode/decrypt stuff from an older session/setting.

Oliver

On 4/17/26 11:27, Pekka Länsiaho wrote:
> Hello again,
>
> We have been a bit slow with the system updates, and since v3.32 was a 
> breaking change we had to put off updates entirely for a while, so I 
> am trying to remediate that now.
> I have managed to upgrade configuration following instructions in the 
> change log 
> https://openxpki.readthedocs.io/en/master/upgrading.html#release-v3-32, 
> and got both server and client services running after upgrade to 
> v3.32.15 and using community config v3.32.8. (Old system version was 
> v3.30.9, not quite sure which config version, but I believe the 
> community branch commit was 17b96e5)
> System is running Debian 12.13.
>
> /openxpkictl status server/ and /client/ both report running and 
> accepting requests, and both clients and serviced logs have no 
> indication of errors.
>
> However, when accessing webui at 
> https://openxpki/webui/index/#/openxpki/welcome, application error 
> appears: "/The webserver did not return the expected data. Possible 
> causes: OpenXPKI client is not running; authentication session has 
> expired; an internal error. HTTP code: 503/".
>
> And upon inspecting /var/log/openxpki/webui.log, I am met with these 
> lines:
> /ERR Unable to decrypt cookie (AES: Data size must be multiple of 
> blocksize (16 bytes) at /usr/share/perl5/Crypt/CBC.pm line 492.) at 
> /usr/share/perl5/OpenXPKI/Client/Service/WebUI/SessionCookie.pm line 214./
> /ERR Error creating backend client: Unable to connect to socket 
> [sid=....]/
> /ERR Backend service is not reachable or not responding [sid=....]/
>
> I tried to look at the newly provided 'sampleconfig.sh' file to see if 
> there was a step I might have missed compared to a fresh system 
> install, but couldn't immediately point to any particular step, 
> unfortunately.
>
> Help would be much appreciated, my eyes grow tired of comparing things.
>
>
> best regards,
> Pekka
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users

-- 
Protect your environment -  close windows and adopt a penguin!

[OpenXPKI-users] Webui unable to communicate with backend after upgrade

[Pekka L. <pek...@gm...>]

Hello again,

We have been a bit slow with the system updates, and since v3.32 was a
breaking change we had to put off updates entirely for a while, so I am
trying to remediate that now.
I have managed to upgrade configuration following instructions in the
change log
https://openxpki.readthedocs.io/en/master/upgrading.html#release-v3-32, and
got both server and client services running after upgrade to v3.32.15 and
using community config v3.32.8. (Old system version was v3.30.9, not quite
sure which config version, but I believe the community branch commit
was 17b96e5)
System is running Debian 12.13.

*openxpkictl status server* and *client* both report running and accepting
requests, and both clients and serviced logs have no indication of errors.

However, when accessing webui at
https://openxpki/webui/index/#/openxpki/welcome, application error appears:
"*The webserver did not return the expected data. Possible causes: OpenXPKI
client is not running; authentication session has expired; an internal
error. HTTP code: 503*".

And upon inspecting /var/log/openxpki/webui.log, I am met with these lines:
*ERR Unable to decrypt cookie (AES: Data size must be multiple of blocksize
(16 bytes) at /usr/share/perl5/Crypt/CBC.pm line 492.) at
/usr/share/perl5/OpenXPKI/Client/Service/WebUI/SessionCookie.pm line 214.*
*ERR Error creating backend client: Unable to connect to socket [sid=....]*
*ERR Backend service is not reachable or not responding [sid=....]*

I tried to look at the newly provided 'sampleconfig.sh' file to see if
there was a step I might have missed compared to a fresh system install,
but couldn't immediately point to any particular step, unfortunately.

Help would be much appreciated, my eyes grow tired of comparing things.


best regards,
Pekka

[OpenXPKI-users] New maintenance release 3.32.15 available

[Oliver W. <ow...@wh...>]

Hello OpenXPKI Fellows,

we have just published a new maintenance relase 3.32.15, there are also 
updates to the workflows in the configuration repository.

The release introduces new condition classes, so be aware that the 
recent configuration will NOT WORK with older packages! We encourage 
anybody to always use the most recent packages / docker images but if 
you have a reason to stay behind make sure your config matches! The 
config repo comes with tags that marks the current version at the time 
of packaging.

Any feedback is welcome :)

With greetings from the rabbithole and the openxpki team.

Oliver

-- 
White Rabbit Security GmbH, Werner-Heisenberg-Str. 8, 85254 Sulzemoos
Contact: +49 8135 314 000-0, of...@wh...
Director: Martin Bartosch, Scott T. Hardin, Dr. Oliver Welter

[OpenXPKI-users] New maintenance release 3.32.15 available

[Oliver W. <ma...@ol...>]

Hello OpenXPKI Fellows,

we have just published a new maintenance relase 3.32.15, there are also 
updates to the workflows in the configuration repository.

The release introduces new condition classes, so be aware that the 
recent configuration will NOT WORK with older packages! We encourage 
anybody to always use the most recent packages / docker images but if 
you have a reason to stay behind make sure your config matches! The 
config repo comes with tags that marks the current version at the time 
of packaging.

Any feedback is welcome :)

With greetings from the rabbithole and the openxpki team.

Oliver

-- 
Protect your environment -  close windows and adopt a penguin!

Re: [OpenXPKI-users] Unable to create Certificate Revocation Requests

[Oliver W. <ma...@ol...>]

Hi Herbert,

yes that is exactly the reason and the latest head does unfortunately 
not match the recent release packages as I accidentially pushed the 
config before updating the packages / containers. The "community" branch 
is now back on the 3.32.8 tag so it matches the latest release.

Oliver

On 3/24/26 13:49, Herbert Baum wrote:
> Hello,
>
> As it happens all too often: The solution hit me a short time after hitting send. The openxpki-config has to match the server version. The commit revision that I used is also tagged v3.32.13.. a mismatch to the docker image version.
>
> I hope this could still help someone with the same problem.
>
> Best regards
> Herbert
>
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>
-- 
Protect your environment -  close windows and adopt a penguin!

Re: [OpenXPKI-users] Unable to create Certificate Revocation Requests

[Herbert B. <pk...@90...>]

Hello,

As it happens all too often: The solution hit me a short time after hitting send. The openxpki-config has to match the server version. The commit revision that I used is also tagged v3.32.13.. a mismatch to the docker image version.

I hope this could still help someone with the same problem.

Best regards
Herbert

[OpenXPKI-users] Unable to create Certificate Revocation Requests

[Herbert B. <pk...@90...>]

Hello,

Using dockerized OpenXPKI in v3.32.8 and unmodified workflows (but small changes in profiles) from openxpki-config/community in version 0b140fd441d4a61cbdd2f303b60942462114977d.

We are experiencing the following issue: When a certificate revocation request for a valid, issued certificate is created in the Webinterface, the workflow fails with the message "Unable to load workflow information." displayed in the Webinterface. Workflow history looks like this:

> 2026-03-24 10:35:27	INITIAL	crr_initialize	EXECUTE	hbaum	7e3a28e67f7f
> 2026-03-24 10:35:27	INITIAL_CRR_INITIALIZE_0	crr_set_workflow_attributes	AUTORUN	hbaum	7e3a28e67f7f
> 2026-03-24 10:35:27	CHECK_BATCHMODE	global_noop	AUTORUN	hbaum	7e3a28e67f7f
> 2026-03-24 10:35:28	PENDING_USER	crr_submit	EXECUTE	hbaum	7e3a28e67f7f
> 2026-03-24 10:35:28	CHECK_NOTIFY	crr_submit	EXCEPTION: State 'CHECK_NOTIFY' should be automatically executed but there are no actions available for execution.	hbaum	7e3a28e67f7f

and server catchall.log with loglevel TRACE says this:

> 2026/03/24 10:36:13 OpenXPKI.Server.Workflow.Condition.CertificateHasStatus.ERROR configuration_error exception thrown from [OpenXPKI::Server::Workflow::Condition::CertificateHasStatus: 29; before: OpenXPKI::Server::Workflow::Condition: 51]: certificate has status expected status missing or invalid [pid=7956|sid=nlUZ]
> 2026/03/24 10:36:13 OpenXPKI.Server.Workflow.Condition.CertificateHasStatus.ERROR configuration_error exception thrown from [OpenXPKI::Server::Workflow::Condition::CertificateHasStatus: 29; before: OpenXPKI::Server::Workflow::Condition: 51]: certificate has status expected status missing or invalid [pid=7956|sid=nlUZ]
> 2026/03/24 10:36:13 openxpki.system.ERROR Attempt to execute activity on workflow that is not in proc_state "manual"; __activity__ => crr_submit, __proc_state__ => exception, __wf_id__ => 30463 [pid=7956|sid=nlUZ]

When a revocation is requested via RPC, the log says this:

> 2026/03/24 10:42:55 openxpki.auth.INFO Login successful (user: Anonymous, role: System) [pid=8413|sid=Sf+a]
> 2026/03/24 10:42:56 Workflow.State.ERROR workflow_error exception thrown from [Workflow::State: 164; before: Workflow: 338]: State 'CHECK_BATCHMODE' should be automatically executed but there are multiple actions available for execution. Actions are: global_check_authorized_signer, global_noop2 [pid=8413|sid=Sf+a]
> 2026/03/24 10:42:56 openxpki.workflow.ERROR Workflow 31487/certificate_revocation_request_v2/CHECK_BATCHMODE uncaught exception [pid=8413|sid=Sf+a]
> 2026/03/24 10:42:56 openxpki.system.ERROR I18N_OPENXPKI_SERVER_WORKFLOW_ERROR_ON_EXECUTE; __ACTION__ => crr_set_workflow_attributes, __ERROR__ => State 'CHECK_BATCHMODE' should be automatically executed but there are multiple actions available for execution. Actions are: global_check_authorized_signer, global_noop2, __EXCEPTION__ => Workflow::Exception [pid=8413|sid=Sf+a]
> 2026/03/24 10:42:56 openxpki.workflow.ERROR Error executing workflow activity "crr_initialize" on workflow id #31487 (type "certificate_revocation_request_v2"): I18N_OPENXPKI_SERVER_WORKFLOW_ERROR_ON_EXECUTE; __ACTION__ => crr_set_workflow_attributes, __ERROR__ => State 'CHECK_BATCHMODE' should be automatically executed but there are multiple actions available for execution. Actions are: global_check_authorized_signer, global_noop2, __EXCEPTION__ => Workflow::Exception [pid=8413|sid=Sf+a]

This issue was IIRC not present before updating our workflows to 0b140fd441d4a61cbdd2f303b60942462114977d. Is there any other information that I can provide?

Thank you for all your work on OpenXPKI and your consideration.

Best regards,
Herbert

Re: [OpenXPKI-users] Error in Logs

[Oliver W. <ma...@ol...>]

Hi,

this is a know bug in the error logging, if the system works properly 
just ignore it - it is already fixed in develop.

Oliver

On 3/13/26 11:45, Alaa Hilal wrote:
> Hello,
>
> In my installation of openxpki, although the main functions that I use 
> in the system work properly, in the logs i have the below FATAL logs 
> that I cannot find the source of:
>
> 2026/03/13 11:26:54 FATAL OpenXPKI::Service::Default->init() failed: 
> I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103966|]
> 2026/03/13 11:31:54 FATAL OpenXPKI::Service::Default->init() failed: 
> I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103981|]
> 2026/03/13 11:36:54 FATAL OpenXPKI::Service::Default->init() failed: 
> I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103994|]
> 2026/03/13 11:41:54 FATAL OpenXPKI::Service::Default->init() failed: 
> I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=104013|]
>
> could you please point me in the right direction in terms of what to 
> check?
>
> Best regards,
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users

-- 
Protect your environment -  close windows and adopt a penguin!

[OpenXPKI-users] Error in Logs

[Alaa H. <ala...@gm...>]

Hello,

In my installation of openxpki, although the main functions that I use in
the system work properly, in the logs i have the below FATAL logs that I
cannot find the source of:

2026/03/13 11:26:54 FATAL OpenXPKI::Service::Default->init() failed:
I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103966|]
2026/03/13 11:31:54 FATAL OpenXPKI::Service::Default->init() failed:
I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103981|]
2026/03/13 11:36:54 FATAL OpenXPKI::Service::Default->init() failed:
I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=103994|]
2026/03/13 11:41:54 FATAL OpenXPKI::Service::Default->init() failed:
I18N_OPENXPKI_TRANSPORT_SIMPLE_CLIENT_READ_CLOSED_CONNECTION [pid=104013|]

could you please point me in the right direction in terms of what to check?

Best regards,

Re: [OpenXPKI-users] Cleaning obsolete database entries

[Martin B. <vc...@cy...>]

Hi,

> Is it safe to clear the application log and the workflow history manually from the database?

You can (and should) use regular logrotation on the log files, so they do not grow independently. Perform log file pruning to your liking and retain the desired backlog.

If you really wish to delete PKI workflow data you can do the following. Test this first thoroughly on a dev system.

It should be safe to delete from the workflow_history table without any repercussions.
Deleting workflow context entries from a workflow instance should be possible if the workflow will not be used again (is in a final state). If you delete workflow context entries of an 
Deleting workflows is a bit more tricky, you will have to first completely delete all dependent entries to not break things.

I advise against deleting certificates, but if you do so, you will also need to delete dependent certificate_attributes.

> Also is it possible to configure the level of logs?

All internal logging is done via Log4Perl, and the corresponding log configuration is located at /etc/openxpk/log.conf - adapt log levels and log targets to your liking.


Cheers

Martin

Re: [OpenXPKI-users] Cleaning obsolete database entries

[Alaa H. <ala...@gm...>]

Thank you for your reply.

Is it safe to clear the application log and the workflow history manually
from the database?
Also is it possible to configure the level of logs?

Best Regards,

On Wed, Mar 4, 2026 at 10:28 AM Martin Bartosch via OpenXPKI-users <
ope...@li...> wrote:

> Hi,
>
> > On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote:
> > Hello,
> >
> > I have been using OpenXPKI for a while and in general all going well.
> The size of the database has grown large. Specifically the tables:
> > - workflow_context
> > - workflow_history
> > - certificate
> > - application_log
> >
> > Obviously as we use the system more, the size will grow, however, I
> wanted to check if there are any functions or commands that we can use to
> make some cleanups on old data that is not needed anymore.
>
>
> In our opinion the PKI should be able to provide information on issued
> certificates, so from my point of view deleting certificates is a no-go.
> The OpenXPKI design philosophy was to establish accountability on the PKI
> operations, which also means that workflow instances, history and context
> do provide useful information on the request and decision process on
> certificate issuance.
>
> However, it is of course possible to clean up the database if so desired.
> For high volume installations we have implemented a cleanup mechanism which
> can be set up to regularly truncate/archive workflows (but not
> certificates) from the database. However, this solution is only available
> in the Enterprise Edition, so I am afraid you will have to roll your own
> cleanup procedure.
>
> Cheers
>
> Martin
>
>
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users
>

Re: [OpenXPKI-users] Use of a custom CA

[Martin B. <vc...@cy...>]

Hi,

> I want to focus now on a simpler path, so remove the default CA in "democa" and replace it with our own. Is it possible? Everything works, but the fact is that in the OpenXPKI server, the token appears as offline. Do you have any suggestions on why it is happening?

Check the log file, it should indicate the cause of the problem.

Cheers

Martin

Re: [OpenXPKI-users] Cleaning obsolete database entries

[Martin B. <vc...@cy...>]

Hi,

> On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote:
> Hello,
> 
> I have been using OpenXPKI for a while and in general all going well. The size of the database has grown large. Specifically the tables:
> - workflow_context
> - workflow_history
> - certificate
> - application_log
> 
> Obviously as we use the system more, the size will grow, however, I wanted to check if there are any functions or commands that we can use to make some cleanups on old data that is not needed anymore.


In our opinion the PKI should be able to provide information on issued certificates, so from my point of view deleting certificates is a no-go. 
The OpenXPKI design philosophy was to establish accountability on the PKI operations, which also means that workflow instances, history and context do provide useful information on the request and decision process on certificate issuance.

However, it is of course possible to clean up the database if so desired. For high volume installations we have implemented a cleanup mechanism which can be set up to regularly truncate/archive workflows (but not certificates) from the database. However, this solution is only available in the Enterprise Edition, so I am afraid you will have to roll your own cleanup procedure.

Cheers

Martin

Re: [OpenXPKI-users] Cleaning obsolete database entries

[Alaa H. <ala...@gm...>]

Hello,

Apologies to bother again, but just checking if there is any info about
this topic

Best Regards,

On Fri, Feb 27, 2026 at 3:30 PM Alaa Hilal <ala...@gm...> wrote:

> Hello,
>
> I have been using OpenXPKI for a while and in general all going well. The
> size of the database has grown large. Specifically the tables:
> - workflow_context
> - workflow_history
> - certificate
> - application_log
>
> Obviously as we use the system more, the size will grow, however, I wanted
> to check if there are any functions or commands that we can use to make
> some cleanups on old data that is not needed anymore.
>
> Best Regards,
>

[OpenXPKI-users] Antw: Cleaning obsolete database entries (Abwesenheitsnotiz)

[Robert B. <bl...@ib...>]

Guten Tag,

vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht
im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr
Schreiben.

Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle
unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib...

Vielen Dank für Ihr Verständnis.

Mit freundlichen Grüßen

Robert Bloch

IBI - Institut für Bildung in der Informationsgesellschaft gGmbH 
Salzufer 22 
10587 Berlin

Fon 
Zentrale 030 – 330 99 89 - 0 
Meine Durchwahl 030 – 330 99 89 -17 
Fax 030 – 330 99 89 01

www.ibi.tu-berlin.de

Wissenschaftlicher Direktor 
Prof. Dr. Ulf Schrader
 
Geschäftsführer 
Morten Hendricks
 
Registergericht 
Berlin-Charlottenburg

Registernummer
HRB 160074 B
 
Steuernummer 
27/640/02054

[OpenXPKI-users] Cleaning obsolete database entries

[Alaa H. <ala...@gm...>]

Hello,

I have been using OpenXPKI for a while and in general all going well. The
size of the database has grown large. Specifically the tables:
- workflow_context
- workflow_history
- certificate
- application_log

Obviously as we use the system more, the size will grow, however, I wanted
to check if there are any functions or commands that we can use to make
some cleanups on old data that is not needed anymore.

Best Regards,

[OpenXPKI-users] R: Use of a custom CA

[De B. E. (RSE-ext) <Eri...@rs...>]

Thank you for the answer.
The fact is that the documentation is missing a lot and it contains also errors.
The batch file that we created was developed step by step using the documentation.
I want to focus now on a simpler path, so remove the default CA in "democa" and replace it with our own. Is it possible? Everything works, but the fact is that in the OpenXPKI server, the token appears as offline. Do you have any suggestions on why it is happening?

Best regards
________________________________
Da: Martin Bartosch via OpenXPKI-users <ope...@li...>
Inviato: mercoledì 25 febbraio 2026 16:36
A: ope...@li... <ope...@li...>
Cc: Martin Bartosch <vc...@cy...>
Oggetto: Re: [OpenXPKI-users] Use of a custom CA

[Non ricevi spesso messaggi di posta elettronica da ope...@li.... Per informazioni sull'importanza di questo fatto, visita https://aka.ms/LearnAboutSenderIdentification.]

Hi Erika,

> I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system.
> According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below:


>  Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server.
> Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated.

The setup script you posted is obviously AI generated and therefore very likely defective. Please understand that we cannot assist you prompting your AI or debugging its defective output.

If you wish to set up your a PKI customized to your requirements, this is very much doable with the existing documentation and the (currently still useful) trove of knowledge on the mailing list. We are happy to help you with any specific questions with regard to particular problems. Describe your problem in a way that we can understand it and we will do our best to help.

Feel free to contact White Rabbit Security if you prefer a professional services with regard to design, configuration, deployment and support of a company PKI. Our OpenXPKI Enterprise Edition offer includes correctly prepared configuration, extensive documentation and fully functional setup according to your particular PKI design.

Cheers

Martin



_______________________________________________
OpenXPKI-users mailing list
Ope...@li...
https://eur05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fopenxpki-users&data=05%7C02%7Cerika.debardi%40rse-web.it%7Ce260e777f2694f7d0f4108de7486d3bd%7C2de962948ad84c67b400a0d5ba661c6f%7C0%7C0%7C639076319746854497%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C60000%7C%7C%7C&sdata=OqoctkUu9oan%2B9LuUnCtgqAqn0YoKuQoDB0RxumJ420%3D&reserved=0<https://lists.sourceforge.net/lists/listinfo/openxpki-users>

RSE SpA ha adottato il Modello Organizzativo ai sensi del D.Lgs.231/2001, in forza del quale l'assunzione di obbligazioni da parte della Società avviene con firma di un procuratore, munito di idonei poteri. RSE adopts a Compliance Programme under the Italian Law (D.Lgs.231/2001). According to this RSE Compliance Programme, any commitment of RSE is taken by the signature of one Representative granted by a proper Power of Attorney.

Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne e' vietata la diffusione in qualsiasi modo o forma. Qualora Lei non fosse la persona destinataria del presente messaggio, La invitiamo a non diffonderlo e ad eliminarlo, dandone gentilmente comunicazione al mittente. The information included in this e-mail and any attachments are confidential and may also be privileged. If you are not the correct recipient, you are kindly requested to notify the sender immediately, to cancel it and not to disclose the contents to any other person.

Re: [OpenXPKI-users] Use of a custom CA

[Martin B. <vc...@cy...>]

Hi Erika,

> I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system.
> According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below:


>  Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server.
> Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated.

The setup script you posted is obviously AI generated and therefore very likely defective. Please understand that we cannot assist you prompting your AI or debugging its defective output.

If you wish to set up your a PKI customized to your requirements, this is very much doable with the existing documentation and the (currently still useful) trove of knowledge on the mailing list. We are happy to help you with any specific questions with regard to particular problems. Describe your problem in a way that we can understand it and we will do our best to help.

Feel free to contact White Rabbit Security if you prefer a professional services with regard to design, configuration, deployment and support of a company PKI. Our OpenXPKI Enterprise Edition offer includes correctly prepared configuration, extensive documentation and fully functional setup according to your particular PKI design. 

Cheers

Martin

[OpenXPKI-users] Antw: Antw: Use of a custom CA (Abwesenheitsnotiz)

[Robert B. <bl...@ib...>]

Guten Tag,

vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht
im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr
Schreiben.

Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle
unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib...

Vielen Dank für Ihr Verständnis.

Mit freundlichen Grüßen

Robert Bloch

IBI - Institut für Bildung in der Informationsgesellschaft gGmbH 
Salzufer 22 
10587 Berlin

Fon 
Zentrale 030 – 330 99 89 - 0 
Meine Durchwahl 030 – 330 99 89 -17 
Fax 030 – 330 99 89 01

www.ibi.tu-berlin.de

Wissenschaftlicher Direktor 
Prof. Dr. Ulf Schrader
 
Geschäftsführer 
Morten Hendricks
 
Registergericht 
Berlin-Charlottenburg

Registernummer
HRB 160074 B
 
Steuernummer 
27/640/02054

[OpenXPKI-users] Antw: Use of a custom CA (Abwesenheitsnotiz)

[Robert B. <bl...@ib...>]

Guten Tag,

vielen Dank für Ihre Nachricht. Ich bin bis zum 27.02.2026 leider nicht
im Hause, kümmere mich aber gerne gleich nach meiner Rückkehr um Ihr
Schreiben.

Ihre Nachricht wird nicht automatisch weitergeleitet. Im Falle
unaufschiebbarer Anliegen schreiben Sie bitte an tt...@ib...

Vielen Dank für Ihr Verständnis.

Mit freundlichen Grüßen

Robert Bloch

IBI - Institut für Bildung in der Informationsgesellschaft gGmbH 
Salzufer 22 
10587 Berlin

Fon 
Zentrale 030 – 330 99 89 - 0 
Meine Durchwahl 030 – 330 99 89 -17 
Fax 030 – 330 99 89 01

www.ibi.tu-berlin.de

Wissenschaftlicher Direktor 
Prof. Dr. Ulf Schrader
 
Geschäftsführer 
Morten Hendricks
 
Registergericht 
Berlin-Charlottenburg

Registernummer
HRB 160074 B
 
Steuernummer 
27/640/02054

[OpenXPKI-users] Use of a custom CA

[De B. E. (RSE-ext) <Eri...@rs...>]

Good morning,
I am currently working with OpenXPKI to implement a custom certificate chain. My goal is to establish a personalized CA hierarchy directly within the system.
According to the documentation, I have proceeded with creating a new realm, generating a private key, and setting up the CA certificate. You can find the batch file containing the configuration steps I followed here below:
set -euo pipefail
REALM_DIR="/etc/openxpki/ca/mia_ca"
REALM_NAME="mia_ca"
CONFIG_REALM_DIR="/etc/openxpki/config.d/realm/${REALM_NAME}"
SYSTEM_REALMS_FILE="/etc/openxpki/config.d/system/realms.yaml"
DEMO_DIR="/etc/openxpki/config.d/realm/democa"
CRYPTO_YAML="${CONFIG_REALM_DIR}/crypto.yaml"
CA_KEY="${REALM_DIR}/ca.key"
CA_CRT="${REALM_DIR}/ca.crt"
echo "Creazione directory per la CA: ${REALM_DIR}"
sudo mkdir -p "${REALM_DIR}"
echo "Generazione chiave privata"
sudo openssl genrsa -out "${CA_KEY}" 4096
sudo chmod 600 "${CA_KEY}"
echo "Generazione cert CA"
sudo openssl req -x509 -new -nodes -key "${CA_KEY}" -sha256 -days 3650 -subj "/CN=Mia Ca Interna/O=MiaAzienda/C=IT" -out "${CA_CRT}"
sudo chown root:root "${REALM_DIR}"/* || true
sudo chmod 644 "${CA_CRT}" || true
if [ -d "${DEMO_DIR}" ]; then
echo "Copia struttura democa in ${CONFIG_REALM_DIR}"
sudo cp -r "${DEMO_DIR}" "${CONFIG_REALM_DIR}"
else
echo "Attenzione: ${DEMO_DIR} non esiste"
sudo mkdir -p "${CONFIG_REALM_DIR}"
sudo mkdir -p "${CONFIG_REALM_DIR}/profile"
sudo mkdir -p "${CONFIG_REALM_DIR}/auth"
fi
if [ -f "${CRYPTO_YAML}" ]; then
echo "Rimuovo ${CRYPTO_YAML}"
sudo rm -f "${CRYPTO_YAML}"
fi
echo "Creazione ${CRYPTO_YAML}"
sudo tee "${CRYPTO_YAML}" > /dev/null <<YAML
type:
certsign: mia_ca_signer
token:
default:
backend: OpenSSL
engine: OpenSSL
key: /etc/openxpki/ca/mia_ca/ca.key
cert: /etc/openxpki/ca/mia_ca/ca.cert
YAML
sudo chmod 640 "${CRYPTO_YAML}"
AUTH_HANDLER="${CONFIG_REALM_DIR}/auth/handler.yaml"
echo "Creazione handler in ${AUTH_HANDLER}"
sudo tee "${AUTH_HANDLER}" > /dev/null <<'YAML'
Anonymous:
type: Anonymous
label: Anonymous
System:
type: Anonymous
label: System
Certificate:
type: ClientX509
role: User
arg: CN
trust_anchor:
realm: mia_ca
LocalPassword:
type: Password
user@: connector:auth.connector.userdb
Password:
type: Password
user:
emma:
digest: '{plain}admin123'
role: user
caop:
digest: '{plain}admin123'
role: CA operator
raop:
digest: '{plain}admin123'
role: RA operator
YAML
sudo chmod 640 "${AUTH_HANDLER}"
if grep -q "^${REALM_NAME}:" "${SYSTEM_REALMS_FILE}" 2>/dev/null; then
echo "Realm ${REALM_NAME} già presente in ${SYSTEM_REALMS_FILE}"
else
echo "Aggiungo ${REALM_NAME} a ${SYSTEM_REALMS_FILE}"
sudo mkdir -p "$(dirname "${SYSTEM_REALMS_FILE}")"
sudo tee -a "${SYSTEM_REALMS_FILE}" > /dev/null <<YAML
${REALM_NAME}:
label: Mia CA Interna
baseurl: https://localhost/webui
YAML
fi
if command -v openxpkiadm >/dev/null 2>&1; then
echo "Verifica realm con 'sudo openxpki certificate list --realm ${REALM_NAME}'"
sudo openxpkiadm certificate list --realm "${REALM_NAME}" || true
else
echo "openxpki non trovato"
fi
if command -v openxpkiadm >/dev/null 2>&1; then
echo "import della CA"
IMPORT_OUTPUT=$(sudo openxpkiadm certificate import --realm "${REALM_NAME}" --file "${CA_CRT}" 2>&1)
echo "${IMPORT_OUTPUT}"
IDENTIFIER=$(echo "${IMPORT_OUTPUT}" | grep -i "identifier" | sed 's/.*identifier[: ]*//i')
if [ -n "$IDENTIFIER" ]; then
echo "identifier trovato: $IDENTIFIER"
echo "aggiunta alias token"
sudo openxpkiadm alias --realm "${REALM_NAME}" --identifier "$IDENTIFIER" --token certsign
else
echo "Errore identfier"
fi
else
echo "Openxpkiadm non trovato"
fi
TLS_SERVER_PROFILE="${CONFIG_REALM_DIR}/profile/tls_server.yaml"
echo "Creazione profilo server in ${TLS_SERVER_PROFILE}"
sudo tee "${TLS_SERVER_PROFILE}" > /dev/null <<'YAML'
subject:
pattern: CN=%cn%,O=MiaAzienda,C=IT
fields:
cn:
label: Nome host server
description: inserisci host name server
type: freetext
extensions:
key_usage:
critical: 1
digital_signature: 1
key_encipherment: 1
extended_key_usage:
critical: 0
server_auth: 1
YAML
TLS_CLIENT_PROFILE="${CONFIG_REALM_DIR}/profile/tls_client.yaml"
echo "Creazione profilo client in ${TLS_CLIENT_PROFILE}"
sudo tee "${TLS_CLIENT_PROFILE}" > /dev/null <<'YAML'
subject:
pattern: CN=%cn%,O=MiaAzienda,C=IT
fields:
cn:
label: Nome utente
description: inserisci nome utente
type: freetext
ou:
label: unità
description: inserisci nome unità o gruppo utente
type: freetext
extensions:
key_usage:
critical: 1
digital_signature: 1
extended_key_usage:
critical: 0
client_auth: 1
YAML
exit 0

Unfortunately, this initial setup was unsuccessful. As a workaround, we attempted to remove the default CA in "democa" and replace it with our own. While this operation and the subsequent token creation were successful, we have encountered a critical issue: the token appears as offline within the OpenXPKI server.
Could you please advise if there is a more straightforward or better-documented procedure for importing a custom CA? Any guidance on why the token might be stuck offline would be greatly appreciated.

Thank you in advance for your assistance.
Best regards,
Erika

[http://signature.rse-web.it/_rse_logo.png]
Erika De Bardi


Ricerca sul Sistema Energetico - RSE S.p.A.
Via R. Rubattino 54 - 20134 Milano
www.rse-web.it<https://www.rse-web.it>

________________________________

[http://signature.rse-web.it/_Leaf.png] Pensa all'ambiente prima di stampare questa email
seguici su         [http://signature.rse-web.it/_linkedin.png] <https://it.linkedin.com/company/ricerca-sul-sistema-energetico---rse-spa>     [http://signature.rse-web.it/_twitter.png] <https://twitter.com/rsenergetico>     [http://signature.rse-web.it/_youtube.png] <https://www.youtube.com/user/RSEmedia>


RSE SpA ha adottato il Modello Organizzativo ai sensi del D.Lgs.231/2001, in forza del quale l'assunzione di obbligazioni da parte della Società avviene con firma di un procuratore, munito di idonei poteri. RSE adopts a Compliance Programme under the Italian Law (D.Lgs.231/2001). According to this RSE Compliance Programme, any commitment of RSE is taken by the signature of one Representative granted by a proper Power of Attorney.

Le informazioni contenute in questo messaggio di posta elettronica sono riservate e confidenziali e ne e' vietata la diffusione in qualsiasi modo o forma. Qualora Lei non fosse la persona destinataria del presente messaggio, La invitiamo a non diffonderlo e ad eliminarlo, dandone gentilmente comunicazione al mittente. The information included in this e-mail and any attachments are confidential and may also be privileged. If you are not the correct recipient, you are kindly requested to notify the sender immediately, to cancel it and not to disclose the contents to any other person.

Re: [OpenXPKI-users] questions regarding customizing workflow certificate_search.yaml

[Oliver W. <ma...@ol...>]

Hello Jan,

welcome to the OpenXPKI users list  :)

the RPC call runs the workflow and the cert_identifier is generated as a 
result of the SearchCertificate call. All the other items call a plugin 
helper to generate other items from the certidentifier, this is simply 
done by looking up the artefacts in the database or parsing the 
certificate. If you run "perldoc 
OpenXPKI::Template::Plugin::Certificate" in the system you can see the 
embed documentation of the module with the methods it exposes (you can 
also browse it in the github repo - the docs are part of the code file).

Its important to have the key defined in the workflow AND add it to the 
output section (this works as a filter to not expose any sensitive data).

Oliver

On 1/29/26 14:15, Jan Uyttersprot via OpenXPKI-users wrote:
> questions regarding customizing workflow certificatesearch
>
> HI,
>
>
>
> Version : OpenXPKI Community Edition v3.32.8
>
>
> when using RPC to run the search certificate workflow I have the 
> following action defined in the workflow/def/certificate_search.yaml :
>
>
>  get_certificate_data:
>         class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext
>         param:
>             _map_notbefore: "[% USE Certificate %][% 
> Certificate.notbefore(context.cert_identifier) %]"
>             _map_notafter: "[% USE Certificate %][% 
> Certificate.notafter(context.cert_identifier) %]"
>             _map_status: "[% USE Certificate %][% 
> Certificate.status(context.cert_identifier) %]"
>             _map_pem: "[% USE Certificate %][% 
> Certificate.pem(context.cert_identifier) %]"
>             _map_cn: "[% USE Certificate %][% 
> Certificate.subject(context.cert_identifier) %]"
>
>
>
> in the client.d/service/rpc/public.yaml rpc config I have
>
>
> SearchCertificate:
>     workflow: certificate_search
>     input:
>       - common_name
>     output:
>       - notbefore
>       - notafter
>       - status
>       - pem
>       - cn
>       - cert_identifier
>
>
> all fields are displayed in the json data array fine.
>
>
> Can someone please explain :
>
>
> - why I dont need to map cert_identifier to return it, cert_identifier 
> seems to be the only value that doesnt need to be mapped to work in 
> output ?
>
> - why I cannot do : _map_whatever: "[% USE Certificate %][% 
> Certificate.cert_identifier(context.cert_identifier) %]" and let it 
> output via the RPC call by adding '- whatever' in the output: list ?
>
> - why I cannot do : _map_keyid: "[% USE Certificate %][% 
> Certificate.subject_key_identifier(context.cert_identifier) %]"  and 
> let it output via the RPC call by adding '- keyid' in the output: list ?
>
>
>
> just trying to make some sense of all this
>
>
> thank you in advance
>
> regards,
>
> Jan
>
>
>
> _______________________________________________
> OpenXPKI-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openxpki-users

-- 
Protect your environment -  close windows and adopt a penguin!

[OpenXPKI-users] questions regarding customizing workflow certificate_search.yaml

[Jan U. <jan...@ti...>]

HI,





Version : OpenXPKI Community Edition v3.32.8



when using RPC to run the search certificate workflow I have the following action defined in the workflow/def/certificate_search.yaml :



 get_certificate_data:
        class: OpenXPKI::Server::Workflow::Activity::Tools::SetContext
        param:
            _map_notbefore: "[% USE Certificate %][% Certificate.notbefore(context.cert_identifier) %]"
            _map_notafter: "[% USE Certificate %][% Certificate.notafter(context.cert_identifier) %]"
            _map_status: "[% USE Certificate %][% Certificate.status(context.cert_identifier) %]"
            _map_pem: "[% USE Certificate %][% Certificate.pem(context.cert_identifier) %]"
            _map_cn: "[% USE Certificate %][% Certificate.subject(context.cert_identifier) %]"





in the client.d/service/rpc/public.yaml rpc config I have 



SearchCertificate:
    workflow: certificate_search
    input:
      - common_name
    output:
      - notbefore
      - notafter
      - status
      - pem
      - cn 
      - cert_identifier



all fields are displayed in the json data array fine.



Can someone please explain :



- why I dont need to map cert_identifier to return it, cert_identifier seems to be the only value that doesnt need to be mapped to work in output ?

- why I cannot do : _map_whatever: "[% USE Certificate %][% Certificate.cert_identifier(context.cert_identifier) %]" and let it output via the RPC call by adding '- whatever' in the output: list ?

- why I cannot do : _map_keyid: "[% USE Certificate %][% Certificate.subject_key_identifier(context.cert_identifier) %]"  and let it output via the RPC call by adding '- keyid' in the output: list ?





just trying to make some sense of all this 



thank you in advance

regards,

Jan

[OpenXPKI-users] Documentation is inconsistent ...

[Thomas G. <t.g...@he...>]

Hello Oliver,

the problem is that the documentation has a lot of errors and is missing 
a lot:

I really tried to follow the all steps in README.md 
<https://github.com/openxpki/openxpki-config/blob/community/README.md> and 
QUICkSTART.md 
<https://github.com/openxpki/openxpki-config/blob/community/QUICKSTART.md> to 
initial create my realm.

But it is impossible to get it to work:

1.) When creating a key/cert the commands create files vault-1.pem and 
vault-1.crt. But already the next step uses file vault.pem and vault.crt 
... (OK, not a big problem but not good, when providing a copy button)
2.) After importing the certificate I should check with ```oxi api 
get_token_info --realm democa -- alias=ca-signer-13```, but it creates 
the following error:

TokenManager failed to create token for ca-signer-13; __ERRVAL__ => No 
certificate found for given alias; __alias__ => ca-signer-13

If I try to check the aliases for my domain with ```openxpkiadm alias 
--real democa```
I get:
=== functional token ===
svault (datasafe):
   Alias     : svault-1
   Identifier: 5yf1ovqpfe0p7zy8FjUmhh-L96g
   NotBefore : 2025-12-08 08:46:37
   NotAfter  : 2026-12-08 08:46:37

ca-signer (certsign):
   Alias     : ca-signer-1
   Identifier: aebqYQ1WlzrkQNPb6Tgsiq5prNY
   NotBefore : 2025-01-27 17:06:05
   NotAfter  : 2035-01-25 17:06:05

ratoken (cmcra):
   not set

ratoken (scep):
   not set

=== root ca ===
current root ca:
   Alias     : root-1
   Identifier: aebqYQ1WlzrkQNPb6Tgsiq5prNY
   NotBefore : 2025-01-27 17:06:05
   NotAfter  : 2035-01-25 17:06:05

upcoming root ca:
   not set

So there  is no alias ca-signer-13

But adjusting this to ca-signer-1 gives the next error:

vault instance id does not match id of encypted data

Sorry, but the documentation might be helpful if you are already 
Openxpki professional but not for a starter with > 30 years working as a 
sysadmin
in Linux and some experiences with PKI and certificates ...

And when I can't find a solution in the docs which I always check before 
asking I try to ask a AI to find maybe a solution.

Greetings,

Thomas

Am 05.12.25 um 19:37 schrieb Oliver Welter:
> Hi,
>
> as already said - please use docs and not AI generated configs and as 
> your config snippets do not match the errror message it is impossible 
> to help.
>
> best regards
>
> Oliver
>
> On 12/3/25 10:07, Thomas Gebert wrote:
>> Hello,
>>
>> I get the following error while starting the server:
>>
>> Dec 03 08:56:25 test-keycloak02.testing.edubw.link 
>> openxpkictl[278617]: Exception during server initialization: No type 
>> given for authentication handler BasicAuth (No type given for 
>> authentication handler BasicAuth) at 
>> /usr/share/perl5/OpenXPKI/Server.pm line 801, <DATA> line 1.
>>
>> But there are types given for the stack and the handler:
>>
>> stack.yaml:
>> _System:
>>   handler: System
>>
>> default:
>>   handler: BasicAuth
>>
>> BasicAuth:
>>   handler: ExternalAuth
>>   type: NoAuth
>>   label: "Keycloak SSO"
>>   param:
>>     envkeys:
>>       username: REMOTE_USER
>>       email: OIDC_CLAIM_email
>>       role: OPENXPKI_SSO_ROLE
>>
>> handler.yaml:
>>
>> # Those stacks are usually required so you should not remove them
>> Anonymous:
>>     type: Anonymous
>>     label: Anonymous
>>
>> System:
>>     type: Anonymous
>>     role: System
>>
>> # Read the userdata from a YAML file defined in auth/connector.yaml
>> LocalPassword:
>>     type: Password
>>     user@: connector:auth.connector.userdb
>>
>> ExternalAuth:
>>   label: Keycloak SSO (NoAuth)
>>   class: OpenXPKI::Server::Authentication::NoAuth
>>   type: NoAuth
>>
>>
>> So I don't understand the error in the log.
>>
>> What is wrong here?
>>
>> Kind regards,
>>
>> Thomas
>>
-- 
Heinlein Consulting GmbH
Schwedter Str. 8/9b, 10119 Berlin
   
https://www.heinlein-support.de
  
Tel: 030 / 40 50 51 - 0
Fax: 030 / 40 50 51 - 19
   
Amtsgericht Berlin-Charlottenburg - HRB 220009 B
Geschäftsführer: Peer Heinlein - Sitz: Berlin