[BUG] EJBCA instance needs restart before SuperAdmin certificate can be used

[VonRehberg]

Describe the Bug

After setting up a fresh EJBCA instance in docker with a superadmin user, it's not possible to access EJBCA WebUI or the REST API using the p12 file of the superadmin. When doing so, EJBCA always responds with an empty response / closes the connection. The EJBCA instance needs to be restarted first and after the restart the instance can be accessed with the superadmin user

To Reproduce

Steps to reproduce the behavior:

1. Start EJBCA container with version 9.0.0 with TLS setup set to simple
2. Generate the SuperAdmin user
3. Add the Super Admin user to the Super Administrator group
4. Try to access EJBCA with the SuperAdmin.p12.

You can either try to access the WebUI which will fail, or try to access the REST API using nodejs:

import axios from "axios";
import { Agent } from "https";
import { readFile } from "fs/promises";

console.log(
  JSON.stringify(
    (
      await axios.get(
        "https://ca.localtest.me:8443/ejbca/ejbca-rest-api/v1/ca",
        {
          httpsAgent: new Agent({
            rejectUnauthorized: true,
            pfx: await readFile("./certs/SuperAdmin.p12"),
            passphrase: "test",
          }),
        }
      )
    ).data
  )
);

Expected Behavior

I woulde expect EJBCA to work right after creating the SuperAdmin user instead of needing a restart.

Screenshots and Logs

Product Deployment

Please complete the following information:

• Deployment format: container
• Version 9.0.0

Desktop

Please complete the following information:

• OS: OS X
• Browser Chrome
• Version 131

[VonRehberg]

FYI: I also tried the clear system cache button, but it didn't help

[primetomas]

I think that is expected. Using "simple" means that TLS configuration is not done for requiring client certificate and WildFly need to be re-configured. I assume the restart didn't use "simple"?

[VonRehberg]

Hi primetomas,
The restart also used simple :-)
But it also happens when using "later" and setting up an own ManagementCA + TLS.

[VonRehberg]

Ah and if it was expected I really wonder why it's nowhere mentioned in the documentation 🤔

[primetomas]

You will find that at https://hub.docker.com/r/keyfactor/ejbca-ce "Quick start - classic workflow" and among the tutorials https://docs.keyfactor.com/ejbca/latest/quick-start-guide-start-ejbca-container-with-clien

"simple" is not meant to be a production start step, but an unsecure demo mode. To do a secure installation with client certificate authentication use the classic workflow.

[VonRehberg]

Good morning!
I don't wanna be picky, but the link you sent doesn't mention anything regarding restarting the container after the superadmin was created.

I got the idea of the "simple" workflow, which I'm not using in my current use case. I just used it to compile some easy reproduction steps for you to check the issue ;-)

Maybe the issue I'm describing is not yet described well enough. But here's the gist:

1. Start a container with TLS setup "simple".
2. Generate the super admin and add it to the role according to the documentation
3. Import the super admin p12 file into the browser
4. Open the web UI
5. The web UI stays empty
6. Restart the container
7. The web UI works

Not sure if it's related to the problem: I use a postgres database and am running it on a M1 Mac. The issue is also reproducible on a different Mac.

BR

[primetomas]

What I am telling you is to NOT start the container with TLS setup "simple" if you want to use a client certificate authentication. Follow the tutorial instead and you do not have to restart the container. As you can see in the tutorial the container is started with TLS_SETUP_ENABLED="true.

[VonRehberg]

I see, but still if I start the container with TLS_SETUP_ENABLED = true it doesn't work.
I don't create the superadmin via WebUI, but via bash script, so maybe this could be the issue. Still seems weird to me:

ejbca.sh ra addendentity --username=SuperAdmin --caname="Management CA" --token=P12 --type=1 --dn="CN=SuperAdmin" --password=test
ejbca.sh ra setclearpwd SuperAdmin test
ejbca.sh batch
cp p12/SuperAdmin.p12 /etc/import/SuperAdmin.p12
ejbca.sh roles addrolemember --role "Super Administrator Role" --with="CertificateAuthenticationToken:WITH_COMMONNAME" --value="SuperAdmin" --caname="Management CA"

[primetomas]

You might want to check that the roles are probably already pre-populated, not need to change roles that are already set up for you.
The end entity is also already there as the console output from the container says. That addendentity command should just result in a failure doesn't it?

Sounds like you try to do too many steps yourself, perhaps you are used to a pure software install from before? The container startup already does everything for you except hand you the P12. Read the console output from the container carefully and run through the tutorial first at least once before modifying the process.

Using the Admin UI worked fine for me, I just tried. Than if you want to script to get the p12 from the CLI instead of the UI...you should do only that step and nothing else.

When following the classic workflow install you should pay attention to the part that says "Delete default public access role after superadmin enrollment", to ensure that you have no more access than you want.

[VonRehberg]

Thanks again Primetomas,
I just tried it with the very basic config and the superadmin is created and I can download the P12 file with a randomly generated password.
However I try to automcatically setup an own CA and issue the superadmin from that CA with a predefined p12 passphrase, so that it can be used in our integration tests.
I guess this will always require a reboot then!?

[primetomas]

Yes because in this scenario you have to add certificates to the TLS trust store, which I guess you do file mounts? And since it is a container, which is not supposed to be operated as a VM, i.e. you go in and to configuration inside the container (which is then not active on another started container), bouncing the container with the proper configs/files mounted is the proper way to to do it. A container should be treated as ephemeral and any started container should be completely identical. This enables things like multiple pods for HA, auto-scaling and other kubernetes things. Bouncing a container/pod on configuration changes should be the expected way. For TLS trust anchors an envoy proxy or ingress in the pod is typically used for highly automated scenarios.