Beginner seeking advice on various aspects of EJBCA

[turnkeyautomation]

** Although I have asked this question on sourceforge forum, but thought of asking here as well as I wasn't sure **
Hey all,

I am very new to EJBCA and have started learning purely from the documentation available on keyfactor's website. After reading and doing some POCs with EJBCA, I am now gearing up to setup EJBCA for uat/prod environment and hence, I am seeking expert advise/pointers from this community. Here are some of the points on which I need advise:

1. Deployment: Till now, during POC, I have used containers for 1 DB, 1 EJBCA container or 2 EJBCA containers without DB for separated root CA and sub CA. This isn't ideal for prod environment so I plan to have separate containers backed up by DB for each container. I will also have server/client CAs in sub CA container to setup mTLS for my application use-case. Is there a docker-compose that I can use to achieve this kinda deployment?
2. Usage of Vault: My cursory read about EJBCA integration with Vault suggests that I will need to use hashicorp-vault-secretsengine but I am inclined to have rootCA in vault and keep subCA outside. I plan to explore CRLs and also leverage OSCP to validate a server/client cert before mTLS is attempted. Is this a feasible use-case? has anyone tried it before?
3. Kubernetes: Has anyone deployed distributed PKI in separate pods on k8s using HELM? Please share where I can get started here? I have checked 2 HELM charts from keyfactor and bitnami but wasn't able to achieve much using both.

Looking forward to hearing back from existing users/masters.

[primetomas]

1. You can find deployment examples here:
   https://github.com/Keyfactor/keyfactorcommunity
   and helm charts here: https://github.com/Keyfactor/ejbca-community-helm

2. Not sure what you mean exactly. The Root CA should use an HSM, where EJBCA have very good support for HSMs.
   Using a vault-secrets engine is only when you want to use the vault API to use the CA, instead of the EJBCA REST API.
   There is a new vault-secrets enging here: https://github.com/Keyfactor/ejbca-vault-pki-engine. It uses one REST API call that is currently only in EJBCA Enterprise however, something that will be fixed for Community later this year.

3. Yes, separate pods should not be a problem. EJBCA is an easy application to distribute as there are either no shared components (if you want separate DBs/HSMs for different PKI parts, or the DB and HSM are the only shared components. Everything only network connected.

[turnkeyautomation]

Thanks for responding to this @primetomas. Let me be more clear about the architecture that I have in mind.

1. I plan to have separate docker containers/k8s pods for root CA and sub CA. In sub CA container, I will also have server and client profiles/CAs to generate respective certs which will be signed by subCA. Since root CA is very critical, I want to keep minimal/no access to rootCA container.
2. I was thinking if there is a way to setup rootCA in Vault itself and still have subCA as a separate docker container/k8s pod, it might help in keeping rootCA safe. Thanks to your comment, I don't think I want to go ejbca-vault-pki-engine route as of now.
3. Reason for not going with vault-pki engine is that I have a use-case where I want OSCP to be accessible over internet. There is a scenario where client machines are available on internet and they should verify the certs before attempting for mTLS. I plan to expose OSCP end-points using haproxy/nginx which will act as mediator between clients on internet and subCA exposing OSCP URL. Let me know if this is confusing or my understanding is incorrect.
4. Alternate way of keeping root CA safe that I have read about is to backup private key of rootCA and then remove it from rootCA docker container using CLI command. As and when needed, root CA's priv key can be restored and CA can be activated. Does it seem correct?

All in all, I am pretty much done with POCs in bits and pieces so trying to glue them together to form a solid arch that works for client/servers on internet as well as private network and rootCA is protected as much as possible. So, any expert comments are welcome as I am exploring.

Thanks in advance.

[primetomas]

Hi,

• If you need to keep the Root CA signing keys secure, you should be using an HSM. That is the way of high security deployments, generate and use the CA signing keys inside an HSM (not only wrapped, but actually never leaving the HSM)
• Another common high security setup is to have air-gapped Root CAs, i.e. on a separate box without network connection. Depending on if you have an audit, and which one you may need one or the other.
• I don't see how vault would keep your Root CA safe? It's just another piece of software, isn't it? It's the CAs private signing keys that are vital to protect (and with an HSM they can not be copied anywhere).
• You can make sure to only start the Root CA when it is to be used. And yeah, there is a method to remove and restore the CAs signing keys if you decide to use software backed keys (on a Soft Crypto Token, where keys are stored encrypted in the database),.
• There are different ways to serve OCSP, from the CA server, from external OCSP responders, or even through CDNs. Different architectures for different solutions depending on security, performance, etc etc.

Not sure if that helps :-), but some notes anyhow.

Cheers,
Tomas