Replacing the default "ManagementCA" for the web admin UI in container deployment

[tmontney]

Naturally, I want to create my own CA with my own information. This includes replacing the certificate, issued by ManagementCA, that the web UI is using. EJBCA, at least in the docker container, uses WildFly. Is the recommendation to go off the instructions for setting up one-way SSL?

https://docs.wildfly.org/32/WildFly_Elytron_Security.html#enable-one-way-ssltls-for-applications

Are there any additional certs or configurations I'd need to adjust?

[primetomas]

Since you have done TLS configuration during the EJBCA setup all you need to do is replace the keystores under standalone/configuration/keystore. You can find some good hints here, https://docs.keyfactor.com/ejbca/latest/install-ejbca-as-a-ca-without-a-management-ca.
For the container you can find documentation on settings to point to a keystore and truststore in the docs as DockerHub.

[tmontney]

Why would I replace the keystore? The keystore contains my desired CA, which was generated by EJBCA itself. The docs indicate that procedure is for migrating another EJBCA/external CA to a new EJBCA instance (where ManagementCA isn't initialized).

The only thing I could think to do was revoke and delete the ManagementCA and restart the docker containers. However, everything still works normally and the admin UI is still using the ManagementCA (figuring EJBCA would pick up the next applicable CA and server cert).

I don't mind tearing down and standing up a new docker instance, if there's a way to configure which CA is initially generated. Or, perhaps it's better to not use the docker container.

[primetomas]

Then I don't understand. The question was about getting your other CA to be used for the TLS server certificate wasn't it? If you have those in the keystores already when your desired CA is already used the for TLS server certificate right?

You can do both ways that you discuss:

• start with an "initial default" Management CA and switch to another one
• don't create a "default" Management CA, but instead create the CA of your choice, your DN, your HSM, etc etc.

There are helm charts, ansible playbooks, and other samples here that you can dig into that can give a lot of information.
https://github.com/Keyfactor?q=ejbca&type=all&language=&sort=

I see you are using the container so I just put that in the title. As you would do if differently if you are deploying from source.

[primetomas]

I just spoke to a colleagues here. If you are using Kubernetes or Podman, having the Pod terminate the TLS connection is a common approach and not terminating that in Eclipse.
I.e. TLS_SETUP=later in https://hub.docker.com/r/keyfactor/ejbca-ce

[tmontney]

Then I don't understand. The question was about getting your other CA to be used for the TLS server certificate wasn't it? If you have those in the keystores already when your desired CA is already used the for TLS server certificate right?

No, I'm starting a CA from scratch using EJBCA. When the docker container first runs, it generates "ManagementCA" which the admin UI uses to issue its server certificate. I generated a new CA, but found no way to replace what the system itself was using.

You can do both ways that you discuss:

* start with an "initial default" Management CA and switch to another one

* don't create a "default" Management CA, but instead create the CA of your choice, your DN, your HSM, etc etc.

There are helm charts, ansible playbooks, and other samples here that you can dig into that can give a lot of information. https://github.com/Keyfactor?q=ejbca&type=all&language=&sort=

I see you are using the container so I just put that in the title. As you would do if differently if you are deploying from source.

I did mention the use of a docker container but also the use of WildFly. Having spent half of Sunday attempting to stand up an instance manually (no docker), I can now see why it wasn't obvious of my use of docker. My apologies.

Never heard of helm charts and have next to no experience with Ansible. Never used Kubernetes, haven't heard of Podman. I would assume those automation tools would be used if deploying from source (no docker)?

The TLS_SETUP=later sounds like I'd use a reverse proxy? If so, that's not the worst option.

I think I'll continue with my deployment from source attempt, helps me better understand the inner-workings.

[primetomas]

Helm charts is all about Kubernetes and Containers.
Ansible is an automation tool that can be used with source deployments.

If you are deploying from source you should look into conf/install.properties.sample where it's documented a lot of configuration options and how to customize your management CA.

The Management CA is only used for issuing TLS certificates for WildFly and for SuperAdmin, nothing else. You can rather easily replace those, but a more common option is to start with the desired configuration of ManagementCA from scratch.