1

I'm looking for a solution to extract the CA from EJBCA instance, put it on an external drive, which is secured in a safe-deposit for instance. So I only keep the sub-ca for signing the end user certificates in the EJBCA instance.

Then I would only put it back when I need to generate again a sub-ca or revoke an already created sub-ca.

This way I can make sure that even if my server is compromised, I'm sure that only the remaining sub-ca are compromised, but my root ca is still valid.

Is there a solution to do such a thing ?

Thanks.

Florent
  • 308
  • 2
  • 7

1 Answers1

5

Having the root CA offline is a sound security policy, so that's a very good start. But if you want it to be entirely separate, you shouldn't first build the root CA and sub CA in the same server and then remove the root CA - instead, you should set them up separately from the start, so that you don't need to go through any extra effort to separate them. I'll be listing a couple of ways of going about it below, and also a way to just lock the keys away while keeping the actual CAs in the same place.

1 - Entirely separate server

The most secure way is to throw money at the problem - i.e. get a separate server for the root CA. Create the root CA on that server. Then go to the server that you'll be running the issuing CA on and create the sub-CA on that one. Have the root CA sign the sub-CA; there's information in the EJBCA user guide on how to do this. Once it's done, you can lock the server with the root CA away.

2 - Separate disk

The second way is to have a separate instance of EJBCA/JBoss and the database (usually MySQL), where all data is stored on a removable disk. The advantage is you don't have an extra server. The disadvantage is some added complexity to the one you have - you need separate config files and systemd startup configs/init files, and so on. But you'd essentially go about it the same way as with a separate server, except instead of shutting the entire server off, you'd shut off the JBoss and database instance, umount the disk their data is at, and lock the disk away.

3 - Removing the keys instead of the disk/server

You can keep the root CA together with the issuing CA(s), but remove its private key. This is effectively crippling it - it's there, but it can't sign anything, so it can't be abused. This is the cheapest way and it also makes it easier when you do use the root-CA. Please do take a backup before testing this the first time!

All steps below are done from the command line, not from the web GUI. You can do some of it from the GUI, but you still need access to the actual server in order to move stuff around, so I find it easier to do everything there to start with.

  1. Export the root CA keys to a PKCS#12-file
$ bin/ejbca.sh ca exportca TestCA /mnt/USBDrive/TestCA.p12
Using JBoss JNDI provider...
Enter keystore password: YourVeryGoodPassword

  1. Umount the USB drive and lock it in your safe.

  2. Remove the keystore from the server

$ bin/ejbca.sh ca removekeystore TestCA
Using JBoss JNDI provider...

If you look at the GUI now, you'll see that TestCA is offline and can't be activated.

  1. When you want to use the root CA again, import the keystore:
$ bin/ejbca.sh ca restorekeystore TestCA /mnt/USBDrive/TestCA.p12 -s SignatureKeyAlias -e EncryptionKeyAlias
Using JBoss JNDI provider...
Enter keystore password: YourVeryGoodPassword
$

And of course remove the keystore again as in step 3 once you're done with whatever it is you're doing.

Community
  • 1
Jenny D
  • 27,780
  • 21
  • 75
  • 114
  • Thanks Jenny, I will give it a try. All those solution seems good, but for simplicity, since we do not want to manage a lot of EJBCA instances, we may opt for the third solution. – Florent Apr 14 '16 at 15:06
  • By the way, I'm low level guy, so for me command line is the best :) – Florent Apr 14 '16 at 15:28
  • @Florent I think that in your place I'd go with the third solution too. If you don't feel that your security requires HSMs and the enterprise version or the PKI appliance, then it's unlikely that the added complexity of an entirely separate root server would be worth it. (I'm not saying that you're wrong for making those choices, you know your needs best - only that they give an inkling of the level of trust & security that you need.) – Jenny D Apr 14 '16 at 17:00
  • Agreed, this is internally our first PKI deployment, we are a small company and our sysadmin team is not yet very confident to deploy all this at once, so let's keep it as simple as possible with an acceptable level of security. – Florent Apr 15 '16 at 07:30
  • @Florent You might want to have a look at the sibling forum [security.se]; there's quite a few questions about PKI there. (Also, in my experience, the technical part of PKI is the easy one. The difficulty is making people agree upon and follow processes to keep tech secure...) – Jenny D Apr 15 '16 at 14:50